14.5 用Bak文件恢復到故障點的奧秘

如果數據庫被損壞，我們就只能利用備份集文件(通常擴展名為BAK)來恢復數據庫，如果備份集中包含了尾日志備份，我們同樣能將數據庫恢復到故障點。

前面我們已經介紹了使用restore headeronly命令可以查看備份集文件的頭部信息。這里的信息和msdb系統數據庫中保存的信息是一致的。

區別在于在刪除數據庫時，我們可以選擇是否同時刪除msdb系統數據庫中的備份信息，而備份集文件的備份信息是存儲在其頭部的，不會隨著msdb系統數據庫的備份信息的刪除而被刪除。

14.5.1 發現的問題

在Management Studio中選擇還原數據庫，選擇從設備還原，設置設備為bak文件，出現如圖14-27所示的【常規】選項卡。

圖14-27 【常規】選項卡

然而，令我們吃驚的是，盡管備份集中有3個日志備份(2個日志備份＋1個尾日志備份)，而且這3個日志備份的LSN是前后續接的，但是在圖14-26中我們只能發現2個日志備份的序列，尾日志備份序列不可見，經過筆者的反復實驗，這個問題始終存在。

因為不能應用尾日志備份，所以肯定不能將數據庫恢復到故障點！那么是不是尾日志備份就不能使用了呢？

14.5.2 解決的辦法

經過若干次反復的實驗，發現始終不能在圖形化操作中解決這個問題。盡管尾日志的備份序列和前面的日志備份序列首尾連接，但是在圖形化界面中確實無法選擇。

作者將目光投向了RESTORE DATABASE和RESTORE LOG語句上。最后成功解決了這個問題。

1．成功的實例

最后成功完成尾日志恢復的語句實例如下。

RESTORE DATABASE [db_test] FROM DISK = N'C:\test2.bak'

WITH FILE = 1,

NORECOVERY,

NOUNLOAD,

REPLACE,

STATS = 10

GO

RESTORE LOG [db_test] FROM DISK = N'C:\test2.bak'

WITH FILE = 2,

NORECOVERY,

NOUNLOAD,

STATS = 10

GO

RESTORE LOG [db_test] FROM DISK = N'C:\test2.bak'

WITH FILE = 3,

NORECOVERY,

NOUNLOAD,

STATS = 10

GO

RESTORE LOG [db_test] FROM DISK = N'C:\test2.bak'

WITH FILE = 4,

NOUNLOAD,

STATS = 10

GO

光盤代碼：\代碼\1407.sql。

2．解決思路

下面的語句為恢復尾日志的語句。

RESTORE LOG [db_test] FROM DISK = N'C:\test2.bak'

WITH FILE = 4,

NOUNLOAD,

STATS = 10

可以看出，上述恢復尾日志的語句和恢復日志序列語句是不同的。

RESTORE LOG [db_test] FROM DISK = N'C:\test.bak'

WITH FILE = 3,

NORECOVERY,

NOUNLOAD,

STATS = 10

最本質的不同，是尾日志恢復少了一個參數NORECOVERY。

3．NORECOVERY參數的奧秘

那么，為什么NORECOVERY參數就可以恢復尾日志呢？

RECOVERY參數指示還原操作回滾任何未提交的事務。在恢復進程后即可隨時使用數據庫。如果既沒有指定NORECOVERY和RECOVERY，也沒有指定STANDBY，則默認為RECOVERY。

NORECOVERY參數指示還原操作不回滾任何未提交的事務。如果稍后必須應用另一個事務日志，則應指定NORECOVERY或STANDBY選項。使用NORECOVERY選項執行脫機還原操作時，數據庫將無法使用。

4．使用方法

還原數據庫備份和一個或多個事務日志時，或者需要多個RESTORE語句(例如還原一個完整的數據庫備份并隨后還原一個完整的差異備份)時，RESTORE需要對所有語句使用WITH NORECOVERY選項，但最后的RESTORE語句除外。

14.5.3 驗證是否恢復到故障點

(1)執行1407.sql，執行結果如圖14-28所示。

圖14-28 執行恢復

(2)執行dbcc log語句，查詢恢復后的數據庫的日志情況如圖14-29所示。

— 第1條日志記錄的Current LSN：0000001e:00000013:0001。

— 最后1條日志記錄的Current LSN：0000001e:00000064:000a。

圖14-29 恢復后的數據庫日志

在圖14-23中，我們知道發生尾日志備份后的數據庫日志的最后一條日志記錄的Cureent LSN為：0000001e:00000050:0001。

由于恢復后的日志記錄的LSN(0000001e:00000144:000a)>故障點時的日志記錄的LSN(0000001e:00000050:0001)，所以我們得出結論，我們的恢復操作確實將數據庫恢復到了故障點。多余出來的LSN是由于備份和恢復操作產生的日志記錄。

(3)理論上我們已經驗證了，那么，按照我們的實驗數據，故障點時的最后一條日志記錄應該出現在恢復后的日志中。

接下來我們執行dbcc log語句查詢日志記錄，發現該日志記錄果然存在于日志記錄中，如圖14-30所示。

圖14-30 恢復后的數據庫日志

(4)我們還可以通過執行查詢數據庫中特定表的數據來判斷是否恢復到了故障點。

執行下列語句，查詢結果顯示有799條數據，正是我們模擬故障點發生時的數據庫中的數據。

select count(*) from db_test.dbo.t_clusterindextest

總結

以上是生活随笔為你收集整理的mysql 事务日志备份_事务日志备份与恢复 5的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。