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

此文檔收集于網(wǎng)絡(luò)，如有侵權(quán)請(qǐng)聯(lián)系網(wǎng)站刪除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ù)庫的活動(dòng)，所以基于這些記錄的活動(dòng)就可以隨心所欲地將數(shù)據(jù)庫的狀態(tài)恢復(fù)到特定的即時(shí)點(diǎn)或恢復(fù)到故障點(diǎn)。然而，不是每個(gè)DBA都能夠正確完成這些操作的。其中的奧秘在哪里呢？本章深入研究事務(wù)日志備份與恢復(fù)操作。14.1 事務(wù)日志備份與恢復(fù)原理下面我們首先來學(xué)習(xí)事務(wù)日志備份與恢復(fù)的原理。14.1.1 事務(wù)日志備份與恢復(fù)原理事務(wù)日志備份只能與完全恢復(fù)模型和大容量日志記錄恢復(fù)模型一起使用。在簡單模型下，事務(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)建事務(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ù)庫在完全備份和日志備份01中間的某個(gè)時(shí)刻，這就是時(shí)點(diǎn)恢復(fù)。這里的時(shí)點(diǎn)必須是合法的（看日志備份的時(shí)間），而不能超出日志備份的時(shí)間序列，否則系統(tǒng)不會(huì)執(zhí)行。比如現(xiàn)在只有日志備份01，其時(shí)刻為12:11，假如我們指定恢復(fù)到12:12，那么這樣的時(shí)點(diǎn)是非法的。14.1.2 事務(wù)日志備份連續(xù)的奧秘連續(xù)的事務(wù)日志備份是備份和恢復(fù)事務(wù)日志的基本要求。那么，什么樣的事務(wù)日志備份是連續(xù)的呢？LSN（日志序列號(hào)）是用于衡量事務(wù)日志備份是否連續(xù)的基本方法。1連續(xù)的事務(wù)日志備份當(dāng)我們通過備份操作形成備份后，我們可以執(zhí)行restore headeronly語句來查看備份集中的事務(wù)日志備份，判斷其是否連續(xù)。restore headeronly from disk=c:test2.bak查看的結(jié)果如圖14-2所示。我們可以得出結(jié)論：該事務(wù)日志備份序列是連續(xù)的！為什么呢？因?yàn)檫@些事務(wù)日志備份的LSN首尾連接，后一個(gè)日志備份的FirstLSN等于前一個(gè)日志備份的LastLSN。 日志備份（編號(hào)2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。 日志備份（編號(hào)3）：FirstLSN：29000000047000001，LastLSN：30000000001900001。 日志備份（編號(hào)4）：FirstLSN：30000000001900001，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ù)模型切換到大容量日志記錄模型，這都是DBA的大忌！假如你的日志備份出現(xiàn)下列情況。那么，這樣的日志序列LSN首尾不能銜接，無法連接起來執(zhí)行恢復(fù)操作！ 日志備份（編號(hào)2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。 日志備份（編號(hào)3）：FirstLSN：30000000001900001，LastLSN：30000000008100001。提示：DBA一定要千方百計(jì)確保當(dāng)前日志和日志備份序列的安全，同時(shí)還要保證日志序列的完整，判斷是否完整的方法就是執(zhí)行restore headeronly語句。14.1.3 恢復(fù)到即時(shí)點(diǎn)的奧秘正是因?yàn)橛辛诉B續(xù)的、完整的事務(wù)日志備份序列，配合一個(gè)完整數(shù)據(jù)庫備份，我們可以將數(shù)據(jù)庫的狀態(tài)恢復(fù)在日志序列中間的任意一個(gè)即時(shí)點(diǎn)。但是，這樣做是有前提條件的。1正確的完整數(shù)據(jù)庫備份首先，必須要有一個(gè)正確的完整數(shù)據(jù)庫備份，為什么這里要強(qiáng)調(diào)“正確”二字呢？如果讀者已經(jīng)對(duì)事務(wù)日志的連續(xù)性概念有正確認(rèn)識(shí)和理解的話，那么這里的“正確”二字就代表完整數(shù)據(jù)庫備份必須是在第1個(gè)日志備份序列的時(shí)間點(diǎn)之間完成的。本書配套光盤收錄了一個(gè)bak備份文件，包括了1個(gè)完整數(shù)據(jù)庫備份和3個(gè)連續(xù)的事務(wù)日志備份，我們看到編號(hào)為1的是完整數(shù)據(jù)庫備份，其余3個(gè)是事務(wù)日志備份。如圖14-3所示。圖14-3 正確的完整數(shù)據(jù)庫備份完整數(shù)據(jù)庫備份的日志區(qū)間是：2900000003580017929000000043400001。第1個(gè)事務(wù)日志備份的區(qū)間是：2900000003580017929000000047000001。所以，這里的完整數(shù)據(jù)庫備份就是正確的，因?yàn)榛謴?fù)完整數(shù)據(jù)庫備份，其狀態(tài)會(huì)停留在事務(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)生了中斷。我們可以把這個(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ù)庫活動(dòng)，數(shù)據(jù)庫的恢復(fù)機(jī)制無憑無據(jù)，如何恢復(fù)？14.1.4 恢復(fù)到故障點(diǎn)的奧秘?zé)o論我們翻閱SQL Server 2005的聯(lián)機(jī)叢書，還是我們查閱有關(guān)的資料，都會(huì)告訴我們：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一般都會(huì)做。2連續(xù)的事務(wù)日志備份序列除非存儲(chǔ)設(shè)備出現(xiàn)故障，否則這個(gè)問題也很好解決。3正確備份最后一個(gè)日志備份和故障點(diǎn)之間的日志這一點(diǎn)在目前的SQL Server 2005的圖書中幾乎沒有提到！稍微有點(diǎn)實(shí)際經(jīng)驗(yàn)的DBA（這里是指真正從事大型數(shù)據(jù)庫管理的DBA），肯定會(huì)意識(shí)到這個(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í)刻的所有日志備份序列是完整的！如圖14-6所示。圖14-6 尾日志備份14.1.5 尾日志備份因此，要想完成故障點(diǎn)的恢復(fù)，就必須完成尾日志的備份。接下來我們就來學(xué)習(xí)尾日志的相關(guān)話題。1尾日志的存儲(chǔ)首先一個(gè)問題，尾日志存儲(chǔ)在哪里？很顯然，答案是當(dāng)前的日志文件中。當(dāng)前日志文件保存的內(nèi)容包括了最后一個(gè)成功的日志備份到當(dāng)前故障點(diǎn)所有的事務(wù)。所以，一旦最后一個(gè)日志文件備份和故障點(diǎn)之間數(shù)據(jù)庫的日志文件不幸發(fā)生介質(zhì)故障，比如存放日志文件的硬盤損壞，那么這種情況下，上帝也無法挽救一個(gè)DBA的命運(yùn)！由此可以看出，日志文件對(duì)數(shù)據(jù)庫，對(duì)DBA的重要性！所以如果無法完成尾日志備份，則只能將數(shù)據(jù)庫恢復(fù)到創(chuàng)建最后一個(gè)事務(wù)日志備份時(shí)的點(diǎn)。自上一次事務(wù)日志備份后對(duì)數(shù)據(jù)庫所做的更改將丟失，必須手工重做。2與正常日志備份的區(qū)別與正常日志備份相似，尾日志備份將捕獲所有尚未備份的事務(wù)日志記錄。但尾日志備份與正常日志備份在下列幾個(gè)方面有所不同。 如果數(shù)據(jù)庫損壞或離線，則可以嘗試進(jìn)行尾日志備份。僅當(dāng)日志文件未損壞且數(shù)據(jù)庫不包含任何大容量日志更改時(shí)，尾日志備份才會(huì)成功。如果數(shù)據(jù)庫包含要備份的、在記錄間隔期間執(zhí)行的大容量日志更改，則僅在所有數(shù)據(jù)文件都存在且未損壞的情況下，尾日志備份才會(huì)成功。 尾日志備份可使用COPY_ONLY選項(xiàng)獨(dú)立于定期日志備份進(jìn)行創(chuàng)建。僅復(fù)制備份不會(huì)影響備份日志鏈。事務(wù)日志不會(huì)被尾日志備份截?cái)?，并且捕獲的日志將包括在以后的正常日志備份中。這樣就可以在不影響正常日志備份過程的情況下進(jìn)行尾日志備份，例如，為了準(zhǔn)備進(jìn)行在線還原。 如果數(shù)據(jù)庫損壞，則尾日志可能會(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ù)庫的狀態(tài)。14.2 尾日志備份對(duì)于將數(shù)據(jù)庫恢復(fù)到即時(shí)點(diǎn)，很好理解也很好操作。下面我們重點(diǎn)來研究將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)時(shí)必不可少的操作，即尾日志備份。但是，需要注意的是，如果在Management Studio中按照默認(rèn)設(shè)置是永遠(yuǎn)無法完成尾日志備份的。14.2.1 圖形化尾日志備份操作圖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)卡14.2.2 用Backup Log語句完成尾日志備份也可以直接執(zhí)行Backup Log語句來完成日志備份。下面介紹該語句的語法形式。1語法形式Backup Log語句的語法形式如下。BACKUP LOG database_name | database_name_var TO ,.n MIRROR TO ,.n .next-mirror WITH BLOCKSIZE = blocksize | blocksize_variable , CHECKSUM | NO_CHECKSUM , STOP_ON_ERROR | CONTINUE_AFTER_ERROR , DESCRIPTION = text | text_variable , EXPIREDATE = date | date_var | RETAINDAYS = days | days_var , PASSWORD = password | password_variable , FORMAT | NOFORMAT , INIT | NOINIT , NOSKIP | SKIP , MEDIADESCRIPTION = text | text_variable , MEDIANAME = media_name | media_name_variable , MEDIAPASSWORD = mediapassword | mediapassword_variable , NAME = backup_set_name | backup_set_name_var , NO_TRUNCATE , NORECOVERY | STANDBY = undo_file_name , NOREWIND | REWIND , NOUNLOAD | UNLOAD , RESTART , STATS = percentage , COPY_ONLY 2主要參數(shù)對(duì)于其他參數(shù)讀者可以參閱聯(lián)機(jī)叢書的有關(guān)說明。與備份尾日志有關(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：通過放棄活動(dòng)日志以外的所有日志，無須備份復(fù)制日志即可刪除不活動(dòng)的日志部分，并截?cái)嗳罩?。該選項(xiàng)會(huì)釋放空間。因?yàn)椴⒉槐４嫒罩緜浞?，所以沒有必要指定備份設(shè)備。NO_LOG和TRUNCATE_ONLY是同義的。使用NO_LOG或TRUNCATE_ONLY截?cái)嗳罩竞?，記錄在日志中的更改不可恢?fù)。為了進(jìn)行恢復(fù)，請(qǐng)立即執(zhí)行BACKUP DATABASE以執(zhí)行完整備份或完整差異備份。3使用方法要備份尾日志，主要使用Truncate_Only參數(shù)就可以。本書的實(shí)例代碼如下。BACKUP LOG db_test TO DISK = NC:test2.bak WITH NO_TRUNCATE , NOFORMAT, NOINIT, NAME = Ndb_test-事務(wù)日志 備份, SKIP, NOREWIND, NOUNLOAD, 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不了解這其中的奧秘，往往會(huì)想當(dāng)然地認(rèn)為利用已有的備份日志就可以將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)，忘記實(shí)際上還需要做一次日志備份才能恢復(fù)的奧秘。接下來我們通過一個(gè)具體的實(shí)例來完成將數(shù)據(jù)庫恢復(fù)到故障點(diǎn)的功能。14.3.1 案例設(shè)計(jì)案例的設(shè)計(jì)和完成的思路如下。1案例步驟（1）新建數(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ū)間。（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ù)到故障點(diǎn)時(shí)的重要性。讀者可以深刻理解聯(lián)機(jī)日志千萬不能出故障的根本原因。14.3.2 產(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）按照?qǐng)D14-10所示界面產(chǎn)生完整數(shù)據(jù)庫備份。圖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。 LastLSN：29000000043400001。3產(chǎn)生第1次日志備份（1）執(zhí)行下列代碼刪除99條記錄。Delete from db_test.dbo.t_clusterindextestWhere t_t_id99 AND t_t_id故障點(diǎn)時(shí)的日志記錄的LSN（0000001e:00000050:0001），所以我們得出結(jié)論，我們的恢復(fù)操作確實(shí)將數(shù)據(jù)庫恢復(fù)到了故障點(diǎn)。多余出來的LSN是由于備份和恢復(fù)操作產(chǎn)生的日志記錄。（3）理論上我們已經(jīng)驗(yàn)證了，那么，按照我們的實(shí)驗(yàn)數(shù)據(jù)，故障點(diǎn)時(shí)的最后一條日志記錄應(yīng)該出現(xiàn)在恢復(fù)后的日志中。接下來我們執(zhí)行dbcc log語句查詢?nèi)罩居涗?，發(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í)的數(shù)據(jù)庫中的數(shù)據(jù)。select count(*) from db_test.dbo.t_clusterindextest14.6 備份與恢復(fù)疑難問題接下來介紹備份與恢復(fù)中的一些疑難問題。14.6.1 恢復(fù)中的單用戶模式問題1故障現(xiàn)象在在線恢復(fù)數(shù)據(jù)庫時(shí)，出現(xiàn)如圖14-31所示界面，提示“數(shù)據(jù)庫正在使用，所以無法獲得對(duì)數(shù)據(jù)庫的獨(dú)占訪問權(quán)”。圖14-31 故障現(xiàn)象2原因分析這是因?yàn)樵谶€原數(shù)據(jù)庫時(shí)，有其他用戶正在使用數(shù)據(jù)庫。還原數(shù)據(jù)庫要求數(shù)據(jù)庫工作在單用戶模式。通常就是DBA在操作時(shí)，不允許其他用戶連接數(shù)據(jù)庫。3解決方法配置數(shù)據(jù)庫的屬性，在如圖14-32所示的【選項(xiàng)】選項(xiàng)卡中，設(shè)置【限制訪問】參數(shù)為“Single”即可。圖14-32 【選項(xiàng)】選項(xiàng)卡設(shè)置完畢查看