14.5 用Bak文件恢復(fù)到故障點(diǎn)的奧秘

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

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

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

14.5.1 發(fā)現(xiàn)的問題

在Management Studio中選擇還原數(shù)據(jù)庫，選擇從設(shè)備還原，設(shè)置設(shè)備為bak文件，出現(xiàn)如圖14-27所示的【常規(guī)】選項卡。

圖14-27 【常規(guī)】選項卡

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

因為不能應(yīng)用尾日志備份，所以肯定不能將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)！那么是不是尾日志備份就不能使用了呢？

14.5.2 解決的辦法

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

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

1．成功的實(shí)例

最后成功完成尾日志恢復(fù)的語句實(shí)例如下。

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．解決思路

下面的語句為恢復(fù)尾日志的語句。

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

WITH FILE = 4,

NOUNLOAD,

STATS = 10

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

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

WITH FILE = 3,

NORECOVERY,

NOUNLOAD,

STATS = 10

最本質(zhì)的不同，是尾日志恢復(fù)少了一個參數(shù)NORECOVERY。

3．NORECOVERY參數(shù)的奧秘

那么，為什么NORECOVERY參數(shù)就可以恢復(fù)尾日志呢？

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

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

4．使用方法

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

14.5.3 驗證是否恢復(fù)到故障點(diǎn)

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

圖14-28 執(zhí)行恢復(fù)

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

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

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

圖14-29 恢復(fù)后的數(shù)據(jù)庫日志

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

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

(3)理論上我們已經(jīng)驗證了，那么，按照我們的實(shí)驗數(shù)據(jù)，故障點(diǎn)時的最后一條日志記錄應(yīng)該出現(xiàn)在恢復(fù)后的日志中。

接下來我們執(zhí)行dbcc log語句查詢?nèi)罩居涗?#xff0c;發(fā)現(xiàn)該日志記錄果然存在于日志記錄中，如圖14-30所示。

圖14-30 恢復(fù)后的數(shù)據(jù)庫日志

(4)我們還可以通過執(zhí)行查詢數(shù)據(jù)庫中特定表的數(shù)據(jù)來判斷是否恢復(fù)到了故障點(diǎn)。

執(zhí)行下列語句，查詢結(jié)果顯示有799條數(shù)據(jù)，正是我們模擬故障點(diǎn)發(fā)生時的數(shù)據(jù)庫中的數(shù)據(jù)。

select count(*) from db_test.dbo.t_clusterindextest

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。