事務(wù)日志備份與還原

?事務(wù)日志備份與恢復(fù)原理一個(gè)不懂事務(wù)日志的DBA，是很難掌握數(shù)據(jù)庫(kù)的精髓的。事務(wù)日志忠實(shí)地記錄了數(shù)據(jù)庫(kù)的活動(dòng)，所以基于這些記錄的活動(dòng)就可以隨心所欲地將數(shù)據(jù)庫(kù)的狀態(tài)恢復(fù)到特定的即時(shí)點(diǎn)或本章深入研究事務(wù)日志備份與恢復(fù)操作。14.1事務(wù)日志備份與恢復(fù)原理下面我們首先來(lái)學(xué)習(xí)事務(wù)日志備份與恢復(fù)的原理。14.1.1事務(wù)日志備份與恢復(fù)原理事務(wù)日志備份只能與完全恢復(fù)模型和大容量日志記錄恢復(fù)模型一起使用。在簡(jiǎn)單模型可以使用事務(wù)日志備份將數(shù)據(jù)庫(kù)恢復(fù)到特定的即時(shí)點(diǎn)（如輸入多余數(shù)據(jù)前的那一點(diǎn)）或當(dāng)SQLServer2005到達(dá)事務(wù)日志地創(chuàng)建事務(wù)日志備份。經(jīng)常備份將減少丟失數(shù)據(jù)的危險(xiǎn)。圖14-1所示為基于完全恢復(fù)模型下的1個(gè)完全備份＋N個(gè)連續(xù)的事務(wù)日志備份的策略。如果中間的日志備份02刪除或者損壞，則數(shù)據(jù)庫(kù)只能恢復(fù)到日志備份01的即時(shí)點(diǎn)。假如日志備份01、02和03都是完整的，那么在恢復(fù)時(shí)，先恢復(fù)數(shù)據(jù)庫(kù)完全備份，然完整，如果是完整的，可以做一個(gè)當(dāng)前日志的備份，然后依次恢復(fù)日志備份04就可以了?？梢栽诨謴?fù)數(shù)據(jù)庫(kù)完全備份后，恢復(fù)數(shù)據(jù)庫(kù)在完全備份和日志備份01中間的某個(gè)時(shí)刻，這間序列，否則系統(tǒng)不會(huì)執(zhí)行。比如現(xiàn)在只有日志備份01，其時(shí)刻為12:11，假如我們指定恢復(fù)到12:12，那么這樣的時(shí)點(diǎn)是非法的。14.1.2事務(wù)日志備份連續(xù)的奧秘中的事務(wù)日志備份，判斷其是否連續(xù)。restoreheaderonlyfromdisk='c:\test2.bak'因?yàn)檫@些事務(wù)日志備份的LSN首尾連接，后一個(gè)日志備份的FirstLSN等于前一個(gè)日志—日志備份（編號(hào)2FirstLSN：290179，LastLSN：290001?！罩緜浞荩ň幪?hào)3FirstLSN：290001，LastLSN：300001。—日志備份（編號(hào)4FirstLSN：300001，LastLSN：300001。290179。終點(diǎn)是最后一個(gè)日志備份的LastLSN：300001。不連續(xù)的日志備份就是指在產(chǎn)生的日志備份序列中，出現(xiàn)了前后首尾不能續(xù)接的情況。這種情況主要發(fā)生在初學(xué)或者剛開始做DBA的讀者身上，不斷切換數(shù)據(jù)庫(kù)的恢復(fù)模型，比如從簡(jiǎn)單恢復(fù)模型切換到完全恢復(fù)模型，或者從完全恢復(fù)模型切換到大容量日志記錄模型，假如你的日志備份出現(xiàn)下列情況。那么，這樣的日志序列LSN首尾不能銜接，無(wú)法連—日志備份（編號(hào)2FirstLSN：290179，LastLSN：290001?！罩緜浞荩ň幪?hào)3FirstLSN：300001，LastLSN：300001。14.1.3恢復(fù)到即時(shí)點(diǎn)的奧秘將數(shù)據(jù)庫(kù)的狀態(tài)恢復(fù)在日志序列中間的任意一個(gè)即時(shí)點(diǎn)。但是，這樣做是有前提條件的。首先，必須要有一個(gè)正確的完整數(shù)據(jù)庫(kù)備份，為什么這里要強(qiáng)調(diào)“正確”二字呢？如果讀者已經(jīng)對(duì)事務(wù)日志的連續(xù)性概念有正確認(rèn)識(shí)和理解的話，那么這里的“正確”二字就代表完整數(shù)據(jù)庫(kù)備份必須是在第1個(gè)日志備份序列的時(shí)間點(diǎn)之間完成的。事務(wù)日志備份1中間的某個(gè)即時(shí)點(diǎn)。然后可以連續(xù)執(zhí)行事務(wù)日志備份來(lái)進(jìn)行恢復(fù)。就是完整數(shù)據(jù)庫(kù)備份完成的即時(shí)點(diǎn)處于日志備份序列之外。如圖14-4所示。我們可以把這個(gè)過(guò)程理解為火車的工作機(jī)制?；疖囶^（完整數(shù)據(jù)庫(kù)備份）和車廂（日志即時(shí)點(diǎn)）！同樣，如果車廂之間發(fā)生斷裂（事務(wù)日志備份序列斷裂），我們就只能走到相連接的部分（恢復(fù)連續(xù)的日志備份序列），其余部分沒有任何意義！這句話的含義是，永遠(yuǎn)不要指望將數(shù)據(jù)庫(kù)的狀態(tài)恢復(fù)到日志序列記錄的LSN區(qū)間之外！這很好理解，因?yàn)長(zhǎng)SN沒有記錄的數(shù)據(jù)庫(kù)活動(dòng)，數(shù)據(jù)庫(kù)的恢復(fù)機(jī)制無(wú)憑無(wú)據(jù)，如何恢14.1.4恢復(fù)到故障點(diǎn)的奧秘?zé)o論我們翻閱SQLServer2005的聯(lián)機(jī)叢書，還是我們查閱有關(guān)的資料，都會(huì)告訴我我們首先從原理上來(lái)理解恢復(fù)到故障點(diǎn)的奧秘，如圖14-5所示。從圖中我們可以看出，要將數(shù)據(jù)庫(kù)恢復(fù)到故障點(diǎn)，必須滿足3個(gè)條件。除非存儲(chǔ)設(shè)備出現(xiàn)故障，否則這個(gè)問(wèn)題也很好解決。這一點(diǎn)在目前的SQLServer2005的圖書中幾乎沒有提到！稍微有點(diǎn)實(shí)際經(jīng)驗(yàn)的DBA（這里是指真正從事大型數(shù)據(jù)庫(kù)管理的DBA），肯定會(huì)意識(shí)到這個(gè)問(wèn)題的嚴(yán)重性！那么，在最后一個(gè)日志備份完成的時(shí)刻到故障點(diǎn)之間的日志呢？等待DBA的將是被老板炒魷魚的悲慘命運(yùn)！因此，要想完成故障點(diǎn)的恢復(fù)，就必須完成尾日志的備份。接下來(lái)我們就來(lái)學(xué)習(xí)尾日志志備份到當(dāng)前故障點(diǎn)所有的事務(wù)。比如存放日志文件的硬盤損壞，那么這種情況下，上帝也無(wú)法挽救一個(gè)DBA的命運(yùn)！點(diǎn)。自上一次事務(wù)日志備份后對(duì)數(shù)據(jù)庫(kù)所做的更改將丟與正常日志備份在下列幾個(gè)方面有所不同?！绻麛?shù)據(jù)庫(kù)損壞或離線，則可以嘗試進(jìn)行尾日志備份。僅當(dāng)日志文件未損壞且數(shù)據(jù)庫(kù)不包含任何大容量日志更改時(shí)，尾日志備份才會(huì)成功。如果數(shù)據(jù)庫(kù)包含要備份的、在記錄間隔期間執(zhí)行的大容量日志更改，則僅在所有數(shù)據(jù)文件都存在且未損壞的情況下，尾日志備份才會(huì)成功?！踩罩緜浞菘墒褂肅OPY_ONLY選項(xiàng)獨(dú)立于定期日志備份進(jìn)行創(chuàng)建。僅復(fù)制備份不會(huì)影響備份日志鏈。事務(wù)日志不會(huì)被尾日志備份截?cái)?，并且捕獲的日志將包括在以后的正常日志備份中。這樣就可以在不影響正常日志備份過(guò)程的情況下進(jìn)行尾日志備份，例如，為了準(zhǔn)備進(jìn)行在線還原。—如果數(shù)據(jù)庫(kù)損壞，則尾日志可能會(huì)包含不完整的元數(shù)據(jù)，這是因?yàn)槟承┩ǔ？捎糜谌罩緜浞莸脑獢?shù)據(jù)在尾日志備份中可能會(huì)不可用。使用CONTINUE_AFTER_ERROR進(jìn)行的日志備份可能會(huì)包含不完整的元數(shù)據(jù)，這是因?yàn)榇诉x項(xiàng)將通知進(jìn)行日志備份而不考慮數(shù)據(jù)庫(kù)的狀態(tài)。對(duì)于將數(shù)據(jù)庫(kù)恢復(fù)到即時(shí)點(diǎn)，很好理解也很好操作。下面我們重點(diǎn)來(lái)研究將數(shù)據(jù)庫(kù)恢復(fù)到故障點(diǎn)時(shí)必不可少的操作，即尾日志備份。14.2.1圖形化尾日志備份操作圖14-7所示為選擇日志備份的數(shù)據(jù)庫(kù)的【選項(xiàng)】選項(xiàng)卡。默認(rèn)情況下選擇的是【截?cái)嗍聞?wù)日志】單選按鈕，這樣將永遠(yuǎn)無(wú)法備份尾日志。也可以直接執(zhí)行BackupLog語(yǔ)句來(lái)完成日志備份。下面介紹該語(yǔ)句的語(yǔ)法形式。BACKUPLOG{database_name|@database_{]}對(duì)于其他參數(shù)讀者可以參閱聯(lián)機(jī)叢書的有關(guān)說(shuō)明。與備份尾日志有關(guān)的主要參數(shù)如下?！狽O_TRUNCATE：只與BACKUPLOG一起使用。指定不截?cái)嗳罩?，并使?shù)據(jù)庫(kù)引擎嘗試執(zhí)行備份，而不考慮數(shù)據(jù)庫(kù)的狀態(tài)。該選項(xiàng)允許在數(shù)據(jù)庫(kù)損壞時(shí)備份日—BACKUPLOG的NO_TRUNCATE選項(xiàng)相當(dāng)于同時(shí)指定COPY_ONLY和CONTINUE_AFTER_ERROR?！狽O_LOG|TRUNCATE_ONLY：通過(guò)放棄活動(dòng)日志以外的所有日志，無(wú)須備份復(fù)制日志即可刪除不活動(dòng)的日志部分，并截?cái)嗳罩?。該選項(xiàng)會(huì)釋放空間。因?yàn)椴⒖苫謴?fù)。為了進(jìn)行恢復(fù)，請(qǐng)立即執(zhí)行BACKUPDATABASE以執(zhí)行完整備份或完整要備份尾日志，主要使用Truncate_Only參數(shù)就可以。本書的實(shí)例代碼如下。WITHNO_TRUNCATE,NOFORMAT,NAME=N'db_test-事務(wù)日志備份',SKIP,NOREWIND,NOUNLOAD,NORECOVERY,通過(guò)前面的學(xué)習(xí)，我們已經(jīng)知道SQLServer2005數(shù)據(jù)庫(kù)提供了將數(shù)據(jù)庫(kù)的狀態(tài)恢復(fù)壞，否則將丟失最后一次日志備份完成時(shí)刻到故障點(diǎn)的事務(wù)。很多DBA不了解這其中的奧秘，往往會(huì)想當(dāng)然地認(rèn)為利用已有的備份日志就可以將數(shù)接下來(lái)我們通過(guò)一個(gè)具體的實(shí)例來(lái)完成將數(shù)據(jù)庫(kù)恢復(fù)到故障點(diǎn)的功能。案例的設(shè)計(jì)和完成的思路如下。（1）新建數(shù)據(jù)庫(kù)db_test，數(shù)據(jù)庫(kù)工作在完全恢復(fù)模型下，新建表t_clusterindextest，向表中錄入1001條數(shù)據(jù)。查詢得到數(shù)據(jù)庫(kù)的日志文件記錄的日志區(qū)間。（2）做一次完整數(shù)據(jù)庫(kù)備份。查詢得到備份后的數(shù)據(jù)庫(kù)的日志區(qū)間和備份集中的日志（3）刪除99條數(shù)據(jù)，產(chǎn)生事務(wù)日志，查詢得到數(shù)據(jù)庫(kù)的日志區(qū)間。（4）第1次完成事務(wù)日志備份，按照默認(rèn)設(shè)置就可以，即不是尾日志備份。查詢備份后的數(shù)據(jù)庫(kù)日志區(qū)間和備份集的日志區(qū)間。（5）刪除101條數(shù)據(jù)，產(chǎn)生事務(wù)日志，查詢得到數(shù)據(jù)庫(kù)的日志區(qū)間。（6）第2次完成事務(wù)日志備份，按照默認(rèn)設(shè)置就可以，即不是尾日志備份。查詢備份后的數(shù)據(jù)庫(kù)日志區(qū)間和備份集的日志區(qū)間。（8）備份尾日志，然后嘗試進(jìn)行恢復(fù)操作。在備份過(guò)程形成的最后的備份集中，我們可以這樣來(lái)進(jìn)行驗(yàn)證。（1）利用完整數(shù)據(jù)庫(kù)備份＋日志備份1，可以將數(shù)據(jù)庫(kù)恢復(fù)到刪除99條記錄的狀態(tài)。（2）利用完整數(shù)據(jù)庫(kù)備份＋日志備份1＋日志備份2，可以恢復(fù)到將數(shù)據(jù)庫(kù)刪除200條記錄的狀態(tài)，而無(wú)法將數(shù)據(jù)庫(kù)恢復(fù)到刪除201條記錄的狀態(tài)。備份來(lái)將數(shù)據(jù)庫(kù)恢復(fù)到刪除201條記錄的狀態(tài)?？汤斫饴?lián)機(jī)日志千萬(wàn)不能出故障的根本原因。接下來(lái)介紹如何形成備份集。按照與前面章節(jié)同樣的辦法，創(chuàng)建新的db_test數(shù)據(jù)庫(kù)。創(chuàng)建表t_clusterindextest，生執(zhí)行dbcclog命令查詢此時(shí)數(shù)據(jù)庫(kù)的日—第1條日志記錄的CurrentLSN：0000001d:0000001a:0001?！詈?條日志記錄的CurrentLSN：0000001d:00000137:00a2。—第1條日志記錄的CurrentLSN：0000001d:00000166:00b3。—最后1條日志記錄的CurrentLSN：0000001d:000001b5:0003。（3）執(zhí)行restoreheaderonly命令查詢備份集中圖14-12產(chǎn)生完整數(shù)據(jù)庫(kù)備份后的備份集日志?—FirstLSN：290179。?—LastLSN：290001。Deletefromdb_test.dbo.t_clusterindextestWherettid<=99—第1條日志記錄的CurrentLSN：0000001d:00000166:00b3?！詈?條日志記錄的CurrentLSN：0000001d:000001ba:0067。WITHNOFORMAT,NAME=N'db_test-事務(wù)日志備份SKIP,NOREWIND,NOUNLOAD,—第1條日志記錄的CurrentLSN：0000001d:00000166:00b3。—最后1條日志記錄的CurrentLSN：0000001d:000001ba:0067。Deletefromdb_test.dbo.t_clusterindextestWherettid>99ANDttid<=200—第1條日志記錄的CurrentLSN：0000001d:00000166:00b3。—最后1條日志記錄的CurrentLSN：0000001e:00000010:0008。（4）執(zhí)行dbcclog命令查詢備份后的數(shù)據(jù)庫(kù)—第1條日志記錄的CurrentLSN：0000001e:00000013:0001?！詈?條日志記錄的CurrentLSN：0000001e:00000027:0001。（5）執(zhí)行restoreheaderonly命令查詢備份集中deletefromdb_test.dbo.t_clusterindextestwherettid=555—第1條日志記錄的CurrentLSN：0000001e:00000013:0001?！詈?條日志記錄的CurrentLSN：0000001e:0000004c:0005。（1）選擇備份日志，在如圖14-21所示的選項(xiàng)卡中選擇進(jìn)行尾日志備所有的操作執(zhí)行完畢后，執(zhí)行dbcclog命令查詢數(shù)據(jù)庫(kù)的日志如圖14-23所示?！?條日志記錄的CurrentLSN：0000001e:00000013:0001?！詈?條日志記錄的CurrentLSN：0000001e:00000050:0001。14.4在線恢復(fù)到故障點(diǎn)據(jù)庫(kù)msdb中存儲(chǔ)的數(shù)據(jù)庫(kù)備份信息，但使用的日志還是備份集中的日志。14.4.1存儲(chǔ)備份信息的系統(tǒng)表信息，可以通過(guò)執(zhí)行下列語(yǔ)句來(lái)完成。select*frommsdb.dbo.backupset14.4.2在線恢復(fù)到故障點(diǎn)在ManagementStudio中選擇還原數(shù)據(jù)庫(kù)，出現(xiàn)如圖14-26所示的【常規(guī)】選項(xiàng)卡。如果數(shù)據(jù)庫(kù)被損壞，我們就只能利用備份集文件（通常擴(kuò)展名為BAK）來(lái)恢復(fù)數(shù)據(jù)庫(kù)，如果備份集中包含了尾日志備份，我們同樣能將數(shù)據(jù)庫(kù)恢復(fù)到故障點(diǎn)。前面我們已經(jīng)介紹了使用restoreheaderonly命令可以查看備份集文件的頭部信息。這里的信息和msdb系統(tǒng)數(shù)據(jù)庫(kù)中保存的信息是一致的。在ManagementStudio中選擇還原數(shù)據(jù)庫(kù)，選擇從設(shè)備還原，設(shè)置設(shè)備為bak文件，然而，令我們吃驚的是，盡管備份集中有3個(gè)日志備份（2個(gè)日志備份＋1個(gè)尾日志備份），而且這3個(gè)日志備份的LSN是前后續(xù)接的，但是在圖14-26中我們只能發(fā)現(xiàn)2個(gè)日志備份的序列，尾日志備份序列不可見，經(jīng)過(guò)筆者的反復(fù)實(shí)驗(yàn)，這個(gè)問(wèn)題始終存在。份序列和前面的日志備份序列首尾連接，但是在圖形化界面中確實(shí)無(wú)法選擇。最后成功完成尾日志恢復(fù)的語(yǔ)句實(shí)例如下。NORECOVERY,NOUNLOAD,REPLACE,NORECOVERY,NOUNLOAD,NORECOVERY,NOUNLOAD,NOUNLOAD,下面的語(yǔ)句為恢復(fù)尾日志的語(yǔ)句。NOUNLOAD,可以看出，上述恢復(fù)尾日志的語(yǔ)句和恢復(fù)日志序列語(yǔ)句是不同的。NORECOVERY,NOUNLOAD,最本質(zhì)的不同，是尾日志恢復(fù)少了一個(gè)參數(shù)NORECOVERY。RECOVERY參數(shù)指示還原操作回滾任何未提交的事務(wù)。在恢復(fù)進(jìn)程后即可隨時(shí)使用數(shù)據(jù)庫(kù)。如果既沒有指定NORECOVERY和RECOVERY，也沒有指定STANDBY，則默認(rèn)為RECOVERY。NORECOVERY參數(shù)指示還原操作不回滾任何未提交的事務(wù)。如果稍后必須應(yīng)用另一個(gè)事務(wù)日志，則應(yīng)指定NORECOVERY或STANDBY選項(xiàng)。使用NORECOVERY選項(xiàng)執(zhí)行脫機(jī)還原操作時(shí)，數(shù)據(jù)庫(kù)將無(wú)法使用。還原數(shù)據(jù)庫(kù)備份和一個(gè)或多個(gè)事務(wù)日志時(shí)，或者需要多個(gè)RESTORE語(yǔ)句（例如還原一WITHNORECOVERY選項(xiàng)，但最后的RESTORE語(yǔ)句除外。14.5.3驗(yàn)證是否恢復(fù)到故障點(diǎn)（2）執(zhí)行dbcclog語(yǔ)句，查詢恢復(fù)后的數(shù)據(jù)庫(kù)的日志情況如圖14-29—第1條日志記錄的CurrentLSN：0000001e:00000013:0001?！詈?條日志記錄的CurrentLSN：0000001e:00000064:000a。在圖14-23中，我們知道發(fā)生尾日志備份后的數(shù)據(jù)庫(kù)日志的最后一條日志記錄的Curee由于恢復(fù)后的日志記錄的LSN（0000001e:SN（0000001e:00000050:0001），所以我們得出結(jié)論，我們的恢復(fù)操作確實(shí)將數(shù)據(jù)庫(kù)恢復(fù)到了故障點(diǎn)。多余出來(lái)