您的位置：首页 > 数据库

如何使用SQL 日志恢复数据

2010-06-10 11:05 369 查看

How do I recover data from SQL Server's log files?

There are several tools available for reviewing SQL Server log files, and restoring data that was accidentally lost or corrupted, say, after your last backup. Three such products are:

Apex SQL Log

Log Explorer

SQL Log Rescue

What follows is the reason this article was written in the first place... a big OOPS by yours truly, and a surprisingly easy procedure for turning that OOPS into a complete recovery (using Lumigent's Log Explorer).

Let's say I create a database called foobar, create a table called foo1, and populate the table with some fictitious data:

SET NOCOUNT ON

CREATE DATABASE foobar
GO

USE foobar
GO

CREATE TABLE foo1
(
id INT PRIMARY KEY,
relID INT
)

SET NOCOUNT ON

INSERT foo1 VALUES(1, 1)
INSERT foo1 VALUES(2, 5)
INSERT foo1 VALUES(3, 3)
INSERT foo1 VALUES(4, 2)
INSERT foo1 VALUES(5, 7)
INSERT foo1 VALUES(6, 9)
INSERT foo1 VALUES(7, 4)
INSERT foo1 VALUES(8, 5)

Now let's say I've thrown away the table or file that showed me those relationships of id <-> relID and allowed me to create the above INSERT statements. I've also closed this Query Analyzer window, so I can't even recover the script I used to populate the table. (Pretend, for a moment, that the script was too long to be memorized.)

So now, I want to UPDATE one row, and I open a new Query Analyzer window and say:

UPDATE foo1 SET relID = 5

After I hit F5, I realize: oh dear, I forgot to add a WHERE clause. I just updated all of the data in my table! I wasn't in a transaction, so I can't roll back. I don't have a backup, so I can't restore. What do I do?

Lumigent's Log Explorer that will allow you to easily parse SQL Server's logs and recover data after an irreparable event, such as a DELETE or UPDATE without a WHERE clause, not within a transaction, and before a single backup has been performed.

So, I can open Log Explorer, select Attach Log File:

Then I can Connect, and then I can select my database and Attach:

Next, I want to move to Filter Log Records so I can only show MODIFY ROW statements:

If I move to Browse / View Log, you can see that I can scroll through my six update statements (remember, two of them did not apply because the data didn't change):

If I right-click and choose Undo Transaction, I will be presented with a set of reverse operations in a file called Recovery.sql. In this case, the output is as follows:

UPDATE [dbo].[foo1] SET [relID] = 4 WHERE [id] = 7 AND [relID] = 5
UPDATE [dbo].[foo1] SET [relID] = 7 WHERE [id] = 5 AND [relID] = 5
UPDATE [dbo].[foo1] SET [relID] = 2 WHERE [id] = 4 AND [relID] = 5
UPDATE [dbo].[foo1] SET [relID] = 3 WHERE [id] = 3 AND [relID] = 5
UPDATE [dbo].[foo1] SET [relID] = 1 WHERE [id] = 1 AND [relID] = 5
UPDATE [dbo].[foo1] SET [relID] = 9 WHERE [id] = 6 AND [relID] = 5

Now you can restore your data as it was, before the fat-fingered UPDATE statement!

Some further information about Log Explorer:

Log Explorer can read SQL Server's online transaction log and transaction log backup files on disk. There is no limit to the size or length of history in the logs, but the log backups must be SQL Server format on a disk Log Explorer can read.

Log Explorer can read the transaction log regardless of the Recovery Model (Simple, Bulk, or Full). However, if the recovery model is set to Simple (Truncate Log On Checkpoint ON for SQL Server 7) then SQL Server can overwrite transactions in the log. If transactions are overwritten by SQL or for any other reason (e.g. a TRUNCATE operation) they do not exist, then Log Explorer obviously cannot find them. So, Bulk and Full Recovery models are recommended to ensure coverage by Log Explorer.

As you can see from some of the screenshots, there is a lot of functionality buried in Log Explorer. I highly recommend downloading the evaluation version and playing with it against Pubs, to see how powerful it really is.