I just migrated a SQL Server 2008 database while the sales staff went to lunch. I did a full backup and then copied the backup to the new server where I restored it to the new SQL Server installation.
The staff got back from lunch and told me that a few of the recent deals they put in right before lunch were no longer showing up in the system. Upon investigation it seems that the full backup was not including some of the very recent data that was added to the database before the backup was performed.
I suspect there is something I'm not accounting for that relates to the transaction log, but not being a MSSQL specialist, I'm not quite sure what I'm doing wrong. Could someone point me in the right direction?
Did you back up just the database, or with transaction logs as well? My guess is that you didn't backup transaction logs, which will contain recent transactions not yet flushed down to the mdb file.
The data may have been entered in an open transaction. Since the backup has to adhere to the ACID model, if a transaction was started before the backup started and was not committed by the time the backup has completed, the transaction will be rolled back upon restoring the database.
This is why you never do these things during a work day! Next time do this over the weekend and close the database off to users by putting it in single user mode. They could have added the data after your backup or during it if you didn't lock them out first.
Related
I have some very strange problems. I have an application running on Windows 2003 terminal server from multiple clients. The application uses SQL Server 2008 Express as its database.
Yesterday, I connected to the app, closed some sessions on the server that were not responding, and to my surprise, I saw that some data was missing from the database. After a futher search I found that all the database changes made from last week were lost.
It's like the database rolled back all the changes, and returned to the state of one week ago! I can confirm that all the changes were lost. In fact I have inserted a record into a table with identity_insert ON (to manually insert an ID on an autonumeric col) and that record is missing, so there is no way this is a program failure.
Does anyone have any idea of what could have happend here?
EDIT
I have a suspect: could a transaction initiated by a session stays in a unconfirmed state for one week, retain all the database changes and when I close the session rollback all the changes made?
EDIT II
Find this on log:
SQL Server never rolls back a database to a previous state (like this). The database was restored, or the entire disk/VM was rolled back, or DML was executed to create the impression that a rollback happened (but really didn't). Maybe someone executed a sync tool in the wrong direction.
The question does not have information that allows for finding the problem. But it certainly isn't SQL Server rolling back a database.
You can try examining the log using fn_dblog.
From the log it looks like the server has only just started up after a reboot or service restart.
If a database is not cleanly shut down then the database can be left with partially applied transactions. If this happens then the database is recovered on start up.
Any transactions that are incomplete are rolled back. Committed transactions that were not yet applied are rolled forwards. How long this recovery takes depends on the size of the transactions in the log that have not yet been applied to the database.
The transactions may not show up in the log after they have been rolled back following a crash. This depends upon their location in the log and the databases's recovery mode.
If the transaction is at the end of the log it is likely the log will just be rolled back and the transaction removed.
If the transaction is in the middle of the log you might see a LOP_ABORT_XACT in the log.
When using simple recovery there is a good chance the log will be cleared after recovery (since the logs are only kept until the transactions are committed).
See Are log records removed from ldf file for rollbacks? for more details.
We have a SQL Server 2005 database whose reovery model is Simple. One of the users has deleted few important records from few tables accidentally. It is not possible to recover the data from SQL Server transaction logs when the recovery modle is Simple. I have heard that there are recovery tools like EnCase, Evidence Eliminator etc., using which one can recover the deleted files from the hard disk. Can it be possible to restore the state of disk files at any point in time? Please provide your inputs.
Thanks in Advance
As shown in this link http://msdn.microsoft.com/en-us/library/ms189275.aspx with simple recovery model there are no log backups, you should restore from a previous backup
I'm helping with a rather ad-hoc disaster recovery, and we've restored a database backup from a few weeks ago and then restored transactions from a transaction log backup.
We did this using SQL Server Management Studio - right click on database, restore full backup but leave in recovery mode, right click again, restore transaction log, etc.
I'm now trying to verify that we had no gaps in our logs. Is it safe to assume that if the SQL Server Management Studio allowed me to restore the logs without errors, then there were no gaps in the logs (e.g. the log chain is complete)?
In other words - would SQL let me restore logs if there were gaps? I assume it would warn me or stop me in that case.
Thanks for any help you can offer ....
We're on SQL 2005 but I think the rules about log chains are similar through all versions.
According to the document Working with Transaction Log Backups from Microsoft:
If a log backup becomes missing or damaged, start a new log chain by creating a full or differential database backup and then backing up the transaction log to start a new log chain. We recommend that you retain transaction logs backups that come before a missing log backup, in case you ever want to restore the database to a point in time within those backups. For information about how to help protect your backups, see Security Considerations for Backup and Restore.
and Creating Transaction Log Backups states:
If a transaction log is damaged, work that is performed since the most recent log backup is lost. This highlights the importance of putting the log files on fault-tolerant storage.
My free reading of this is:
Considering a lost file a kind of file damage, if Management Studio or any other tool allows you to restore the logs without errors, you can be sure the log chain is complete until the last transaction log backup you're applying. You must be sure it is the last transaction log backup available for that database, but that is other thing to think about.
If you don't trust my reading (and the documentation is not too clear on this point), you can make a simple test to be sure: Say you have 10 transaction logs to apply... deliberately delete the 7th (or a random, but not the first nor the last) transaction log, and try your disaster recovery method.
If you get a error saying something like "a transaction log file backup is missing", you can be sure and trust me.
You are correct. SQL will not apply a transaction log backup if it can't be applied, you would have gotten an error.
I am developer so need your advice on how to plan for it
I am having sql server 2008.
I am going to through what they have in maintance wizard
And found that they have full, differential and transaction log.
So if i take one full back once a week then differential backup every day. Not sure how transaction log fit into this.
I assume sql server is saving transaction log some where so in case of failure I can restore from last differential backup coupled with full backup.
What i need to use transaction log on top of it? Where is transaction log saved?
I need this for application data loss issue, if in case some action made it delete some data so i need ability to go back point in time.
You must backup your log too, explicitly. Schedule a job to backup the log at short intervals (15 minutes to an hour usually). When you do a recovery, you apply the full backup, then the newest differential and then all the log backup after the differential.
Only with log backup can you restore the database at a specific moment, using the 'WITH STOP AT'. See: How to: Restore to a Point in Time.
Also to recover from a crash, you backup the log tail then apply the recovery (full->differential->logs->tail) and hopefully occur no data loss at all.
A Zero loss strategy require the involvement of replication in some form. Then you'll also need a failover server to account for replication time before the "slave" server is fully up to date.
Even with transaction log backups your still at risk for losing X data, where X is your transaction log backup interval.
Maybe edit your question?
I really need some help here.
I'm the owner of a SQL Server Database application that lost three days data! I can't understand how or why.
So here is the set-up.
SQL Server 2005 32bit standard edition database on Windows 2000 server. (Database B)
Database is in simple recovery mode
The database is connected as a subscriber to another database(SQL Server 2005 64bit enterprise edition on Win2k3 enterprise) using SQL Server continuous Merge Replication. (Database A)
DatabaseB was rebooted on night X as part of scheduled reboot. When the database came back up it was used as normal for a couple of days and data was created into it perfectly fine.
But then yesterday Day X + 4 it lost a lot of data.
Database B is on a server with another instance of SQL Server and they both started to run out of memory(conflicting with each other).
Here is the sequence of events from the event log when I think this happened.
AppDomain 2 (DatabaseB.dbo[runtime].1) is marked for unload due to memory pressure.
AppDomain 2 (DatabaseB.dbo[runtime].1) unloaded.
BACKUP LOG WITH TRUNCATE_ONLY or WITH NO_LOG is deprecated.
The simple recovery model should be used to automatically truncate the transaction log. (on DatabaseB)
AppDomain 3 (DatabaseB.dbo[runtime].2) created.
I know the data is missing because of my audit logs and that a user had taken a screen shot of some of the data before it was deleted.
So here is my dilema...how could this have happened?
How can several days data go missing from DatabaseB?? (it subsequently is missing from the publication db also!)
Did the truncate with the Appdomain down cause the data to be flushed from the log?
Any and all theories considered. If anyone needs more data I can add it.
Help!
This isn't the answer you want to hear, but in a nutshell, SQL Server doesn't "lose" data. Someone deleted it. If you had the database in full recovery mode, you could use a product like Quest LiteSpeed to read the logs and identify exactly how it was deleted, but in simple mode...sorry, sir, but you're out of luck.
Merge replication is implemented with triggers, so it doesn't need full recovery. Is it possible that someone disabled all triggers in the db? its easy to do DISABLE TRIGGER [database] This would at least account for the subscriber losing data.
Those appdomain lines in the log don't mean that much, its the SQL CLR telling you its unloading assemblies to free up some memory. & then reloading them later on.
Truncating the log removes inactive parts that have been committed to disk, having the recovery model set to simple means there's no point in truncating the log, as the message suggests.
None of this explains why data went missing on both the servers though. There has to be something else that caused this.
How did you verify that for the 4 days when everything was 'created perfectly fine' that it actually was? do you have backups from these days? can you see records with time stamps from those days?
Is it possible there's a ghost in the machine that did a restore without telling you?