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

1、14.1 事務(wù)日志備份與恢復(fù)原理  、本章要點(diǎn) 事務(wù)日志備份與恢復(fù)原理 尾日志備份 產(chǎn)生備份集 將數(shù)據(jù)庫恢復(fù)到故障點(diǎn) 備份恢復(fù)中的疑難問題一個(gè)不懂事務(wù)日志的DBA，是很難掌握數(shù)據(jù)庫的精髓的。事務(wù)日志忠實(shí)地記錄了數(shù)據(jù)庫的活動，所以基于這些記錄的活動就可以隨心所欲地將數(shù)據(jù)庫的狀態(tài)恢復(fù)到特定的即時(shí)點(diǎn)或恢復(fù)到故障點(diǎn)。然而，不是每個(gè)DBA都能夠正確完成這些操作的。其中的奧秘在哪里呢？本章深入研究事務(wù)日志備份與恢復(fù)操作。14.1  事務(wù)日志備份與恢復(fù)原理下面我們首先來學(xué)習(xí)事務(wù)日志備份與恢復(fù)的原理。  事務(wù)日志備份與恢復(fù)原理事務(wù)日志備份只能與完全恢復(fù)模型和大容量日志記錄恢復(fù)模型

2、一起使用。在簡單模型下，事務(wù)日志有可能被破壞，所以事務(wù)日志備份可能不連續(xù)，不連續(xù)的事務(wù)日志備份沒有意義，因?yàn)榛谌罩镜幕謴?fù)要求日志是連續(xù)的?？梢允褂檬聞?wù)日志備份將數(shù)據(jù)庫恢復(fù)到特定的即時(shí)點(diǎn)（如輸入多余數(shù)據(jù)前的那一點(diǎn)）或恢復(fù)到故障點(diǎn)?；謴?fù)事務(wù)日志備份時(shí)，SQL Server 2005重做事務(wù)日志中記錄的所有更改。當(dāng)SQL Server 2005到達(dá)事務(wù)日志的最后時(shí)，已重新創(chuàng)建了與開始執(zhí)行備份操作的那一刻完全相同的數(shù)據(jù)庫狀態(tài)。如果數(shù)據(jù)庫已經(jīng)恢復(fù)，則SQL Server 2005將回滾備份操作開始時(shí)尚未完成的所有事務(wù)。一般情況下，事務(wù)日志備份比數(shù)據(jù)庫備份使用的資源少。因此可以比數(shù)據(jù)庫備份更經(jīng)常地創(chuàng)建事

3、務(wù)日志備份。經(jīng)常備份將減少丟失數(shù)據(jù)的危險(xiǎn)。圖14-1所示為基于完全恢復(fù)模型下的1個(gè)完全備份N個(gè)連續(xù)的事務(wù)日志備份的策略。如果中間的日志備份02刪除或者損壞，則數(shù)據(jù)庫只能恢復(fù)到日志備份01的即時(shí)點(diǎn)。圖14-1  事務(wù)日志備份與恢復(fù)原理假如日志備份01、02和03都是完整的，那么在恢復(fù)時(shí)，先恢復(fù)數(shù)據(jù)庫完全備份，然后依次恢復(fù)日志備份01、02和03。如果要恢復(fù)到故障點(diǎn)，就需要看數(shù)據(jù)庫的當(dāng)前日志是否完整，如果是完整的，可以做一個(gè)當(dāng)前日志的備份，然后依次恢復(fù)日志備份04就可以了?；谑聞?wù)日志的備份還可以恢復(fù)到某個(gè)日志備份中間的時(shí)刻，稱為時(shí)點(diǎn)恢復(fù)。比如我們可以在恢復(fù)數(shù)據(jù)庫完全備份后，恢復(fù)數(shù)據(jù)庫在

4、完全備份和日志備份01中間的某個(gè)時(shí)刻，這就是時(shí)點(diǎn)恢復(fù)。這里的時(shí)點(diǎn)必須是合法的（看日志備份的時(shí)間），而不能超出日志備份的時(shí)間序列，否則系統(tǒng)不會執(zhí)行。比如現(xiàn)在只有日志備份01，其時(shí)刻為12:11，假如我們指定恢復(fù)到12:12，那么這樣的時(shí)點(diǎn)是非法的。  事務(wù)日志備份連續(xù)的奧秘連續(xù)的事務(wù)日志備份是備份和恢復(fù)事務(wù)日志的基本要求。那么，什么樣的事務(wù)日志備份是連續(xù)的呢？LSN（日志序列號）是用于衡量事務(wù)日志備份是否連續(xù)的基本方法。1連續(xù)的事務(wù)日志備份當(dāng)我們通過備份操作形成備份后，我們可以執(zhí)行restore headeronly語句來查看備份集中的事務(wù)日志備份，判斷其是否連續(xù)。restore he

5、aderonly from disk='c:test2.bak'查看的結(jié)果如圖14-2所示。我們可以得出結(jié)論：該事務(wù)日志備份序列是連續(xù)的！為什么呢？因?yàn)檫@些事務(wù)日志備份的LSN首尾連接，后一個(gè)日志備份的FirstLSN等于前一個(gè)日志備份的LastLSN。 日志備份（編號2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。 日志備份（編號3）：FirstLSN：29000000047000001，LastLSN：30000000001900001。 日志備份（編號4）：FirstLSN：30000000001900001

6、，LastLSN：30000000008100001。圖14-2  實(shí)例的事務(wù)日志備份序列因?yàn)楦鶕?jù)這3個(gè)日志備份序列，它記錄的事務(wù)日志起點(diǎn)是第1個(gè)日志備份的FirstLSN：29000000035800179。終點(diǎn)是最后一個(gè)日志備份的LastLSN：30000000008100001。光盤視頻：視頻1402.exe（連續(xù)的事務(wù)日志備份）。2不連續(xù)的事務(wù)日志備份不連續(xù)的日志備份就是指在產(chǎn)生的日志備份序列中，出現(xiàn)了前后首尾不能續(xù)接的情況。這種情況主要發(fā)生在初學(xué)或者剛開始做DBA的讀者身上，不斷切換數(shù)據(jù)庫的恢復(fù)模型，比如從簡單恢復(fù)模型切換到完全恢復(fù)模型，或者從完全恢復(fù)模型切換到大容量日志記

7、錄模型，這都是DBA的大忌！假如你的日志備份出現(xiàn)下列情況。那么，這樣的日志序列LSN首尾不能銜接，無法連接起來執(zhí)行恢復(fù)操作！ 日志備份（編號2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。 日志備份（編號3）：FirstLSN：30000000001900001，LastLSN：30000000008100001。提示：DBA一定要千方百計(jì)確保當(dāng)前日志和日志備份序列的安全，同時(shí)還要保證日志序列的完整，判斷是否完整的方法就是執(zhí)行restore headeronly語句。  恢復(fù)到即時(shí)點(diǎn)的奧秘正是因?yàn)橛辛诉B續(xù)的、完整的事務(wù)日

8、志備份序列，配合一個(gè)完整數(shù)據(jù)庫備份，我們可以將數(shù)據(jù)庫的狀態(tài)恢復(fù)在日志序列中間的任意一個(gè)即時(shí)點(diǎn)。但是，這樣做是有前提條件的。1正確的完整數(shù)據(jù)庫備份首先，必須要有一個(gè)正確的完整數(shù)據(jù)庫備份，為什么這里要強(qiáng)調(diào)“正確”二字呢？如果讀者已經(jīng)對事務(wù)日志的連續(xù)性概念有正確認(rèn)識和理解的話，那么這里的“正確”二字就代表完整數(shù)據(jù)庫備份必須是在第1個(gè)日志備份序列的時(shí)間點(diǎn)之間完成的。本書配套光盤收錄了一個(gè)bak備份文件，包括了1個(gè)完整數(shù)據(jù)庫備份和3個(gè)連續(xù)的事務(wù)日志備份，我們看到編號為1的是完整數(shù)據(jù)庫備份，其余3個(gè)是事務(wù)日志備份。如圖14-3所示。圖14-3  正確的完整數(shù)據(jù)庫備份完整數(shù)據(jù)庫備份的日志區(qū)間是：2

9、900000003580017929000000043400001。第1個(gè)事務(wù)日志備份的區(qū)間是：2900000003580017929000000047000001。所以，這里的完整數(shù)據(jù)庫備份就是正確的，因?yàn)榛謴?fù)完整數(shù)據(jù)庫備份，其狀態(tài)會停留在事務(wù)日志備份1中間的某個(gè)即時(shí)點(diǎn)。然后可以連續(xù)執(zhí)行事務(wù)日志備份來進(jìn)行恢復(fù)。什么是不正確的完整數(shù)據(jù)庫備份呢？就是完整數(shù)據(jù)庫備份完成的即時(shí)點(diǎn)處于日志備份序列之外。如圖14-4所示。圖14-4  事務(wù)日志備份與恢復(fù)原理提示：永遠(yuǎn)也不能指望停留在日志備份之外，即時(shí)點(diǎn)的完整數(shù)據(jù)庫備份和日志備份能夠配合起來進(jìn)行恢復(fù)，因?yàn)橥暾麛?shù)據(jù)庫備份和日志備份的日志序列之間產(chǎn)

10、生了中斷。我們可以把這個(gè)過程理解為火車的工作機(jī)制。火車頭（完整數(shù)據(jù)庫備份）和車廂（日志備份序列）之間首尾相接，所以我們可以從頭走到尾。如果車頭和車廂之間發(fā)生斷裂（不正確的完整數(shù)據(jù)庫備份），我們就只能開走火車頭了（將數(shù)據(jù)庫恢復(fù)到完整數(shù)據(jù)庫備份完成的即時(shí)點(diǎn)）！同樣，如果車廂之間發(fā)生斷裂（事務(wù)日志備份序列斷裂），我們就只能走到相連接的部分（恢復(fù)連續(xù)的日志備份序列），其余部分沒有任何意義！2正確的即時(shí)點(diǎn)這句話的含義是，永遠(yuǎn)不要指望將數(shù)據(jù)庫的狀態(tài)恢復(fù)到日志序列記錄的LSN區(qū)間之外！這很好理解，因?yàn)長SN沒有記錄的數(shù)據(jù)庫活動，數(shù)據(jù)庫的恢復(fù)機(jī)制無憑無據(jù)，如何恢復(fù)？  恢復(fù)到故障點(diǎn)的奧秘?zé)o論我們翻閱

11、SQL Server 2005的聯(lián)機(jī)叢書，還是我們查閱有關(guān)的資料，都會告訴我們：SQL Server 2005擁有將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)的能力！然而，很遺憾的是，沒有一本圖書好好地告訴我們作者是如何將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)的！我們首先從原理上來理解恢復(fù)到故障點(diǎn)的奧秘，如圖14-5所示。圖14-5  恢復(fù)到故障點(diǎn)的奧秘從圖中我們可以看出，要將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)，必須滿足3個(gè)條件。1正確的完整數(shù)據(jù)庫備份這個(gè)很好理解，而且DBA一般都會做。2連續(xù)的事務(wù)日志備份序列除非存儲設(shè)備出現(xiàn)故障，否則這個(gè)問題也很好解決。3正確備份最后一個(gè)日志備份和故障點(diǎn)之間的日志這一點(diǎn)在目前的SQL Server 2005

12、的圖書中幾乎沒有提到！稍微有點(diǎn)實(shí)際經(jīng)驗(yàn)的DBA（這里是指真正從事大型數(shù)據(jù)庫管理的DBA），肯定會意識到這個(gè)問題的嚴(yán)重性！如果我們按照目前的市面上的其他圖書去操作，當(dāng)某個(gè)故障發(fā)生的時(shí)候，我們永遠(yuǎn)無法將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)，因?yàn)槲覀冏疃嘀荒軐?shù)據(jù)庫恢復(fù)到最后一個(gè)日志備份完成的時(shí)刻，那么，在最后一個(gè)日志備份完成的時(shí)刻到故障點(diǎn)之間的日志呢？等待DBA的將是被老板炒魷魚的悲慘命運(yùn)！提示：要想將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)，就必須深刻理解SQL Server 2005的尾日志備份的原理。很顯然，我們必須將這一段特殊的日志（最后日志備份完成時(shí)刻故障點(diǎn)發(fā)生時(shí)刻）備份下來，從而使從完整數(shù)據(jù)庫備份時(shí)刻到故障點(diǎn)時(shí)刻的所有日志備

13、份序列是完整的！如圖14-6所示。圖14-6  尾日志備份  尾日志備份因此，要想完成故障點(diǎn)的恢復(fù)，就必須完成尾日志的備份。接下來我們就來學(xué)習(xí)尾日志的相關(guān)話題。1尾日志的存儲首先一個(gè)問題，尾日志存儲在哪里？很顯然，答案是當(dāng)前的日志文件中。當(dāng)前日志文件保存的內(nèi)容包括了最后一個(gè)成功的日志備份到當(dāng)前故障點(diǎn)所有的事務(wù)。所以，一旦最后一個(gè)日志文件備份和故障點(diǎn)之間數(shù)據(jù)庫的日志文件不幸發(fā)生介質(zhì)故障，比如存放日志文件的硬盤損壞，那么這種情況下，上帝也無法挽救一個(gè)DBA的命運(yùn)！由此可以看出，日志文件對數(shù)據(jù)庫，對DBA的重要性！所以如果無法完成尾日志備份，則只能將數(shù)據(jù)庫恢復(fù)到創(chuàng)建最后一個(gè)事務(wù)日

14、志備份時(shí)的點(diǎn)。自上一次事務(wù)日志備份后對數(shù)據(jù)庫所做的更改將丟失，必須手工重做。2與正常日志備份的區(qū)別與正常日志備份相似，尾日志備份將捕獲所有尚未備份的事務(wù)日志記錄。但尾日志備份與正常日志備份在下列幾個(gè)方面有所不同。 如果數(shù)據(jù)庫損壞或離線，則可以嘗試進(jìn)行尾日志備份。僅當(dāng)日志文件未損壞且數(shù)據(jù)庫不包含任何大容量日志更改時(shí)，尾日志備份才會成功。如果數(shù)據(jù)庫包含要備份的、在記錄間隔期間執(zhí)行的大容量日志更改，則僅在所有數(shù)據(jù)文件都存在且未損壞的情況下，尾日志備份才會成功。 尾日志備份可使用COPY_ONLY選項(xiàng)獨(dú)立于定期日志備份進(jìn)行創(chuàng)建。僅復(fù)制備份不會影響備份日志鏈。事務(wù)日志不會被尾日志備份截?cái)?，并且捕獲的日志

15、將包括在以后的正常日志備份中。這樣就可以在不影響正常日志備份過程的情況下進(jìn)行尾日志備份，例如，為了準(zhǔn)備進(jìn)行在線還原。 如果數(shù)據(jù)庫損壞，則尾日志可能會包含不完整的元數(shù)據(jù)，這是因?yàn)槟承┩ǔ？捎糜谌罩緜浞莸脑獢?shù)據(jù)在尾日志備份中可能會不可用。使用CONTINUE_AFTER_ ERROR進(jìn)行的日志備份可能會包含不完整的元數(shù)據(jù)，這是因?yàn)榇诉x項(xiàng)將通知進(jìn)行日志備份而不考慮數(shù)據(jù)庫的狀態(tài)。14.2  尾日志備份對于將數(shù)據(jù)庫恢復(fù)到即時(shí)點(diǎn)，很好理解也很好操作。下面我們重點(diǎn)來研究將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)時(shí)必不可少的操作，即尾日志備份。但是，需要注意的是，如果在Management Studio中按照默認(rèn)設(shè)置是永

16、遠(yuǎn)無法完成尾日志備份的。  圖形化尾日志備份操作圖14-7所示為選擇日志備份的數(shù)據(jù)庫的【選項(xiàng)】選項(xiàng)卡。默認(rèn)情況下選擇的是【截?cái)嗍聞?wù)日志】單選按鈕，這樣將永遠(yuǎn)無法備份尾日志。提示：要完成尾日志備份，需要在圖14-7中選擇“備份日志尾部，并使數(shù)據(jù)庫處于還原狀態(tài)”選項(xiàng)。圖14-7  【選項(xiàng)】選項(xiàng)卡  用Backup Log語句完成尾日志備份也可以直接執(zhí)行Backup Log語句來完成日志備份。下面介紹該語句的語法形式。1語法形式Backup Log語句的語法形式如下。BACKUP LOG database_name | database_name_var  &

17、#160;   TO <backup_device> ,.n   MIRROR TO <backup_device> ,.n .next-mirror       WITH       BLOCKSIZE = blocksize | blocksize_variable       , CHECKSUM | NO_CHECKSUM     &#

18、160; , STOP_ON_ERROR | CONTINUE_AFTER_ERROR       , DESCRIPTION = 'text' | text_variable       , EXPIREDATE = date | date_var      | RETAINDAYS = days | days_var       , PASSWORD = password |

19、password_variable       , FORMAT | NOFORMAT       , INIT | NOINIT       , NOSKIP | SKIP       , MEDIADESCRIPTION = 'text' | text_variable       , MEDIANAME = media_nam

20、e | media_name_variable       , MEDIAPASSWORD = mediapassword | mediapassword_variable       , NAME = backup_set_name | backup_set_name_var       , NO_TRUNCATE       , NORECOVERY | STANDBY = undo_file

21、_name       , NOREWIND | REWIND       , NOUNLOAD | UNLOAD       , RESTART       , STATS = percentage       , COPY_ONLY       2主要參數(shù)對于其他參數(shù)讀者可以參閱聯(lián)機(jī)叢書的有關(guān)說

22、明。與備份尾日志有關(guān)的主要參數(shù)如下。  NO_TRUNCATE：只與BACKUP LOG一起使用。指定不截?cái)嗳罩?，并使?shù)據(jù)庫引擎嘗試執(zhí)行備份，而不考慮數(shù)據(jù)庫的狀態(tài)。該選項(xiàng)允許在數(shù)據(jù)庫損壞時(shí)備份日志。  BACKUP LOG的NO_TRUNCATE選項(xiàng)相當(dāng)于同時(shí)指定COPY_ONLY和CONTINUE_AFTER_ERROR。  NO_LOG | TRUNCATE_ONLY：通過放棄活動日志以外的所有日志，無須備份復(fù)制日志即可刪除不活動的日志部分，并截?cái)嗳罩?。該選項(xiàng)會釋放空間。因?yàn)椴⒉槐４嫒罩緜浞?，所以沒有必要指定備份設(shè)備。NO_LOG和TRUNCATE_ONLY是

23、同義的。使用NO_LOG或TRUNCATE_ONLY截?cái)嗳罩竞?，記錄在日志中的更改不可恢?fù)。為了進(jìn)行恢復(fù)，請立即執(zhí)行BACKUP DATABASE以執(zhí)行完整備份或完整差異備份。3使用方法要備份尾日志，主要使用Truncate_Only參數(shù)就可以。本書的實(shí)例代碼如下。BACKUP LOG db_test TO  DISK = N'C:test2.bak' WITH  NO_TRUNCATE , NOFORMAT, NOINIT,  NAME = N'db_test-事務(wù)日志 備份', SKIP, NOREWIND, NOUNLOAD,

24、  NORECOVERY ,  STATS = 10GO14.3  產(chǎn)生備份集通過前面的學(xué)習(xí)，我們已經(jīng)知道SQL Server 2005數(shù)據(jù)庫提供了將數(shù)據(jù)庫的狀態(tài)恢復(fù)到故障發(fā)生點(diǎn)的功能。但是這些功能的順利執(zhí)行需要有一些前提條件，比如聯(lián)機(jī)日志不能損壞，否則將丟失最后一次日志備份完成時(shí)刻到故障點(diǎn)的事務(wù)。很多DBA不了解這其中的奧秘，往往會想當(dāng)然地認(rèn)為利用已有的備份日志就可以將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)，忘記實(shí)際上還需要做一次日志備份才能恢復(fù)的奧秘。接下來我們通過一個(gè)具體的實(shí)例來完成將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)的功能。  案例設(shè)計(jì)案例的設(shè)計(jì)和完成的思路如下。1案例步驟（1）新

25、建數(shù)據(jù)庫db_test，數(shù)據(jù)庫工作在完全恢復(fù)模型下，新建表t_clusterindextest，向表中錄入1001條數(shù)據(jù)。查詢得到數(shù)據(jù)庫的日志文件記錄的日志區(qū)間。（2）做一次完整數(shù)據(jù)庫備份。查詢得到備份后的數(shù)據(jù)庫的日志區(qū)間和備份集中的日志區(qū)間。（3）刪除99條數(shù)據(jù)，產(chǎn)生事務(wù)日志，查詢得到數(shù)據(jù)庫的日志區(qū)間。（4）第1次完成事務(wù)日志備份，按照默認(rèn)設(shè)置就可以，即不是尾日志備份。查詢備份后的數(shù)據(jù)庫日志區(qū)間和備份集的日志區(qū)間。（5）刪除101條數(shù)據(jù)，產(chǎn)生事務(wù)日志，查詢得到數(shù)據(jù)庫的日志區(qū)間。（6）第2次完成事務(wù)日志備份，按照默認(rèn)設(shè)置就可以，即不是尾日志備份。查詢備份后的數(shù)據(jù)庫日志區(qū)間和備份集的日志區(qū)間。（

26、7）刪除表中的1條記錄，刪除完畢后模擬故障發(fā)生。（8）備份尾日志，然后嘗試進(jìn)行恢復(fù)操作。案例的步驟可以用圖14-8來表示。圖14-8  案例步驟2驗(yàn)證思路在備份過程形成的最后的備份集中，我們可以這樣來進(jìn)行驗(yàn)證。（1）利用完整數(shù)據(jù)庫備份日志備份1，可以將數(shù)據(jù)庫恢復(fù)到刪除99條記錄的狀態(tài)。（2）利用完整數(shù)據(jù)庫備份日志備份1日志備份2，可以恢復(fù)到將數(shù)據(jù)庫刪除200條記錄的狀態(tài)，而無法將數(shù)據(jù)庫恢復(fù)到刪除201條記錄的狀態(tài)。（3）由于有尾日志備份，所以利用完整數(shù)據(jù)庫備份日志備份1日志備份2尾日志備份來將數(shù)據(jù)庫恢復(fù)到刪除201條記錄的狀態(tài)。3結(jié)論通過上述實(shí)驗(yàn)步驟，說明尾日志備份在將數(shù)據(jù)庫恢復(fù)到故

27、障點(diǎn)時(shí)的重要性。讀者可以深刻理解聯(lián)機(jī)日志千萬不能出故障的根本原因。  產(chǎn)生備份集接下來介紹如何形成備份集。1產(chǎn)生數(shù)據(jù)庫按照與前面章節(jié)同樣的辦法，創(chuàng)建新的db_test數(shù)據(jù)庫。創(chuàng)建表t_clusterindextest，生成1001條數(shù)據(jù)。執(zhí)行dbcc log命令查詢此時(shí)數(shù)據(jù)庫的日志情況如圖14-9所示。 第1條日志記錄的Current LSN：0000001d:0000001a:0001。 最后1條日志記錄的Current LSN：0000001d:00000137:00a2。圖14-9  產(chǎn)生數(shù)據(jù)庫后的日志2產(chǎn)生完整數(shù)據(jù)庫備份（1）按照圖14-10所示界面產(chǎn)生完整數(shù)據(jù)庫備

28、份。圖14-10  產(chǎn)生完整數(shù)據(jù)庫備份（2）執(zhí)行dbcc log命令查詢數(shù)據(jù)庫的日志情況如圖14-11所示。圖14-11  產(chǎn)生完整數(shù)據(jù)庫備份后的日志 第1條日志記錄的Current LSN：0000001d:00000166:00b3。 最后1條日志記錄的Current LSN：0000001d:000001b5:0003。（3）執(zhí)行restore headeronly命令查詢備份集中的日志情況如圖14-12所示。圖14-12  產(chǎn)生完整數(shù)據(jù)庫備份后的備份集日志Ø    FirstLSN：29000000035800179。

29、6;    LastLSN：29000000043400001。3產(chǎn)生第1次日志備份（1）執(zhí)行下列代碼刪除99條記錄。Where t_t_id<=99光盤代碼：代碼1402.sql。（2）執(zhí)行dbcc log命令查詢數(shù)據(jù)庫的日志情況，如圖14-13所示。圖14-13  刪除99條數(shù)據(jù)庫后的數(shù)據(jù)庫日志 第1條日志記錄的Current LSN：0000001d:00000166:00b3。 最后1條日志記錄的Current LSN：0000001d:000001ba:0067。（3）按照圖14-14所示默認(rèn)設(shè)置備份數(shù)據(jù)庫的日志。也可以執(zhí)行下列代碼完成同樣的功能，

30、注意，這里不是完成尾日志備份，而是產(chǎn)生了截?cái)唷ACKUP LOG db_test TO  DISK = N'C:test2.bak'WITH NOFORMAT, NOINIT,  NAME = N'db_test-事務(wù)日志備份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10GO光盤代碼：代碼1403.sql。（4）執(zhí)行dbcc log命令查詢備份后的數(shù)據(jù)庫日志如圖14-15所示。 第1條日志記錄的Current LSN：0000001d:00000166:00b3。 最后1條日志記錄的Current

31、 LSN：0000001d:000001ba:0067。（5）執(zhí)行restore headeronly命令查詢備份集中的日志如圖14-16所示。圖14-14  備份事務(wù)日志圖14-15  第1次日志備份后的數(shù)據(jù)庫日志圖14-16  產(chǎn)生第1次日志備份后的備份集日志4產(chǎn)生第2次日志備份（1）執(zhí)行下列代碼刪除101條記錄。Where t_t_id>99 AND t_t_id<=200光盤代碼：代碼1404.sql。（2）執(zhí)行dbcc log命令查詢刪除后的數(shù)據(jù)庫日志如圖14-17所示。圖14-17  刪除101條記錄后的數(shù)據(jù)庫日志 第1條日志記錄

32、的Current LSN：0000001d:00000166:00b3。 最后1條日志記錄的Current LSN：0000001e:00000010:0008。（3）第2次備份日志，不備份尾日志。（4）執(zhí)行dbcc log命令查詢備份后的數(shù)據(jù)庫的日志，如圖14-18所示。 第1條日志記錄的Current LSN：0000001e:00000013:0001。 最后1條日志記錄的Current LSN：0000001e:00000027:0001。圖14-18  第2次事務(wù)日志備份后的數(shù)據(jù)庫日志（5）執(zhí)行restore headeronly命令查詢備份集中的日志區(qū)間如圖14-19所示

33、。圖14-19  第2次日志備份后的備份集日志5模擬故障發(fā)生（1）執(zhí)行下列代碼刪除1條記錄。where t_t_id=555光盤代碼：代碼1405.sql。（2）執(zhí)行dbcc log命令查詢數(shù)據(jù)庫的日志，如圖14-20所示。圖14-20  模擬故障發(fā)生時(shí)的日志 第1條日志記錄的Current LSN：0000001e:00000013:0001。 最后1條日志記錄的Current LSN：0000001e:0000004c:0005。6尾日志備份（1）選擇備份日志，在如圖14-21所示的選項(xiàng)卡中選擇進(jìn)行尾日志備份。（2）也可以通過執(zhí)行1401.sql來完成同樣的過程，執(zhí)行情

34、況如圖14-22所示。7數(shù)據(jù)庫日志所有的操作執(zhí)行完畢后，執(zhí)行dbcc log命令查詢數(shù)據(jù)庫的日志如圖14-23所示。圖14-21  備份尾日志圖14-22  執(zhí)行尾日志備份的情況圖14-23  執(zhí)行備份完畢后的數(shù)據(jù)庫日志 第1條日志記錄的Current LSN：0000001e:00000013:0001。 最后1條日志記錄的Current LSN：0000001e:00000050:0001。8最終的備份集日志查詢最終的備份集的日志如圖14-24所示。圖14-24  最后的備份集日志14.4  在線恢復(fù)到故障點(diǎn)如果數(shù)據(jù)庫沒有損壞，我們就可以在

35、線將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)。在線恢復(fù)將使用系統(tǒng)數(shù)據(jù)庫msdb中存儲的數(shù)據(jù)庫備份信息，但使用的日志還是備份集中的日志。  存儲備份信息的系統(tǒng)表SQL Server 2005將備份信息統(tǒng)一保存在msdb系統(tǒng)數(shù)據(jù)庫中，要查詢數(shù)據(jù)庫的備份集信息，可以通過執(zhí)行下列語句來完成。光盤代碼：代碼1406.sql。執(zhí)行結(jié)果如圖14-25所示。圖14-25  保存?zhèn)浞菁畔⒌南到y(tǒng)表  在線恢復(fù)到故障點(diǎn)在Management Studio中選擇還原數(shù)據(jù)庫，出現(xiàn)如圖14-26所示的【常規(guī)】選項(xiàng)卡。圖14-26  【常規(guī)】選項(xiàng)卡選擇恢復(fù)完整數(shù)據(jù)庫備份和連續(xù)的3個(gè)日志備份，這樣就可以將

36、數(shù)據(jù)庫的狀態(tài)恢復(fù)到故障點(diǎn)。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ù)庫時(shí)，我們可以選擇是否同時(shí)刪除msdb系統(tǒng)數(shù)據(jù)庫中的備份信息，而備份集文件的備份信息是存儲在其頭部的，不會隨著msdb系統(tǒng)數(shù)據(jù)庫的備份信息的刪除而被刪除。  發(fā)現(xiàn)的問題在Management Studio中選擇

37、還原數(shù)據(jù)庫，選擇從設(shè)備還原，設(shè)置設(shè)備為bak文件，出現(xiàn)如圖14-27所示的【常規(guī)】選項(xiàng)卡。圖14-27 【常規(guī)】選項(xiàng)卡然而，令我們吃驚的是，盡管備份集中有3個(gè)日志備份（2個(gè)日志備份1個(gè)尾日志備份），而且這3個(gè)日志備份的LSN是前后續(xù)接的，但是在圖14-26中我們只能發(fā)現(xiàn)2個(gè)日志備份的序列，尾日志備份序列不可見，經(jīng)過筆者的反復(fù)實(shí)驗(yàn)，這個(gè)問題始終存在。因?yàn)椴荒軕?yīng)用尾日志備份，所以肯定不能將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)！那么是不是尾日志備份就不能使用了呢？  解決的辦法經(jīng)過若干次反復(fù)的實(shí)驗(yàn)，發(fā)現(xiàn)始終不能在圖形化操作中解決這個(gè)問題。盡管尾日志的備份序列和前面的日志備份序列首尾連接，但是在圖形化界面中確

38、實(shí)無法選擇。作者將目光投向了RESTORE DATABASE和RESTORE LOG語句上。最后成功解決了這個(gè)問題。1成功的實(shí)例最后成功完成尾日志恢復(fù)的語句實(shí)例如下。RESTORE DATABASE db_test FROM  DISK = N'C:test2.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 10GORESTORE LOG db_test FROM  DISK = N'C:test2.bak' WI

39、TH  FILE = 2,  NORECOVERY, NOUNLOAD, STATS = 10GORESTORE LOG db_test FROM  DISK = N'C:test2.bak' WITH  FILE = 3, NORECOVERY,  NOUNLOAD,  STATS = 10GORESTORE LOG db_test FROM  DISK = N'C:test2.bak' WITH  FILE = 4,  NOUNLOAD, STATS = 10GO光盤代

40、碼：代碼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ì)的不

41、同，是尾日志恢復(fù)少了一個(gè)參數(shù)NORECOVERY。3NORECOVERY參數(shù)的奧秘那么，為什么NORECOVERY參數(shù)就可以恢復(fù)尾日志呢？RECOVERY參數(shù)指示還原操作回滾任何未提交的事務(wù)。在恢復(fù)進(jìn)程后即可隨時(shí)使用數(shù)據(jù)庫。如果既沒有指定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ù)庫將無法使用。4使用方法還原數(shù)據(jù)庫備份和一個(gè)或多個(gè)事務(wù)日志時(shí)，或者需要多個(gè)R

42、ESTORE語句（例如還原一個(gè)完整的數(shù)據(jù)庫備份并隨后還原一個(gè)完整的差異備份）時(shí)，RESTORE需要對所有語句使用WITH NORECOVERY選項(xiàng)，但最后的RESTORE語句除外。  驗(yàn)證是否恢復(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ù)庫日志的最后一條日志記錄的Curee