修復(fù)受損的數(shù)據(jù)庫(kù)備份文件

故障現(xiàn)象

筆者單位的一臺(tái)Web服務(wù)器近來(lái)數(shù)據(jù)存儲(chǔ)出現(xiàn)異常，因?yàn)楹笈_(tái)采用的是SQL Server數(shù)據(jù)庫(kù)，之前對(duì)其進(jìn)行過(guò)備份，因此決定對(duì)數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)。

本來(lái)數(shù)據(jù)恢復(fù)是簡(jiǎn)單的事情，運(yùn)行“RESTORE DATABASE DBNAME FROM='f:databakXXX.bak '”命令，就可以使用備份文件恢復(fù)數(shù)據(jù)庫(kù)（“DBNAME”表示目標(biāo)數(shù)據(jù)庫(kù)名稱，“xxx.bak”表示備份文件的名稱），但是，在恢復(fù)時(shí)系統(tǒng)提 示“RESTORE cound not start database 'DBNAME' ,file ' DBNAME_log'on file 1”，“RESTORE DATABASE is terminating abnormally”，“SQL SERVER detected a logical consistency-Based I/Oerror:incorrect checksum”等警告信息，說(shuō)明備份文件出現(xiàn)損壞，無(wú)法順利恢復(fù)數(shù)據(jù)。

故障排查

該SQL Server數(shù)據(jù)庫(kù)最近只進(jìn)行了一次備份，如果不能從該受損的備份文件中恢復(fù)數(shù)據(jù)，無(wú)疑會(huì)對(duì)Web服務(wù)器的運(yùn)行造成不利影響。我們知道，當(dāng)SQL Server在進(jìn)行數(shù)據(jù)備份時(shí)，只是簡(jiǎn)單地將數(shù)據(jù)頁(yè)面復(fù)制下來(lái)，一般不會(huì)做數(shù)據(jù)一致性檢查，當(dāng)進(jìn)行數(shù)據(jù)恢復(fù)時(shí)，則需要將數(shù)據(jù)庫(kù)恢復(fù)到事務(wù)一致的某個(gè)時(shí)間點(diǎn)，如果備份文件中的損壞部分對(duì)Redo前滾和Undo后滾造成影響，那么數(shù)據(jù)恢復(fù)就會(huì)出現(xiàn)問(wèn)題。

既然在恢復(fù)備份文件時(shí)出現(xiàn)故障，那么忽略該錯(cuò)誤，讓恢復(fù)操作繼續(xù)進(jìn)行，或許可以完成恢復(fù)操作，至少可以得到盡可能多的有效數(shù)據(jù)。這里使用的是SQL Server 2012，針對(duì)這一故障，可以使用其提供的忽略錯(cuò)誤功能，來(lái)嘗試解決上述故障。

在“RESTORE”命令中提供了名為“CONTINUE_AFTER_ERROR”的參數(shù)，可以讓恢復(fù)操作避開(kāi)錯(cuò)誤提示，嘗試修復(fù)報(bào)告中的所有錯(cuò)誤，盡可能地還原備份文件中所有內(nèi)容。當(dāng)數(shù)據(jù)還原完成后，可以使用后續(xù)的事務(wù)日志備份，來(lái)恢復(fù)數(shù)據(jù)庫(kù)。當(dāng)在恢復(fù)日志時(shí)出現(xiàn)錯(cuò)誤，SQL Server可以在日志中進(jìn)行記錄，禁止用戶訪問(wèn)這些和事務(wù)相關(guān)的頁(yè)面，讓數(shù)據(jù)庫(kù)可以盡可能地聯(lián)機(jī)運(yùn)行。當(dāng)然，這些修復(fù)行為不是萬(wàn)能的，在某些情況下可能丟失部分?jǐn)?shù)據(jù)。對(duì)于一般的數(shù)據(jù)來(lái)說(shuō)，當(dāng)出現(xiàn)錯(cuò)誤時(shí)，會(huì)進(jìn)入可疑狀態(tài)，但不會(huì)影響到恢復(fù)的進(jìn)程。

對(duì)于存在問(wèn)題的頁(yè)面，會(huì)被記錄到相關(guān)的表和日志中。如果數(shù)據(jù)錯(cuò)誤出現(xiàn)在備份文件的關(guān)鍵位置（例如文件頭等），那么恢復(fù)操作將徹底失敗，因此該方法無(wú)法保證解決所有的恢復(fù)失敗故障。當(dāng)數(shù)據(jù)庫(kù)還原之后，還需要使用SQL Server提供的DBCC CHECKDB命令，來(lái)修復(fù)數(shù)據(jù)庫(kù)，讓其可以真正處于可用狀態(tài)。使用該命令，可以有效地檢測(cè)數(shù)據(jù)庫(kù)中是否存在損壞情況，當(dāng)發(fā)現(xiàn)有損壞的跡象時(shí)，可以盡可能地修復(fù)數(shù)據(jù)庫(kù)，使用戶可以正常訪問(wèn)其中的數(shù)據(jù)。

在執(zhí)行該命令時(shí)，會(huì)檢測(cè)一些關(guān)鍵的系統(tǒng)表，在每張數(shù)據(jù)表中都存在聚集索引，通過(guò)檢測(cè)，保證這些表中的所有頁(yè)面以及其中的數(shù)據(jù)可以正常讀出。該命令會(huì)檢查目標(biāo)數(shù)據(jù)庫(kù)中所有頁(yè)面的分配情況，通過(guò)檢驗(yàn)內(nèi)部結(jié)構(gòu)，來(lái)跟蹤這些頁(yè)面以及之間的關(guān)系。同時(shí)，檢測(cè)數(shù)據(jù)庫(kù)中的所有表是否正確鏈接索引，索引是否正常排序，所有指針是否一致，頁(yè)面上的數(shù)據(jù)是否合理，頁(yè)面偏移量是否正確，分區(qū)表或索引的每行是否處于正確的分區(qū)中。可以檢測(cè)數(shù)據(jù)據(jù)庫(kù)中的系統(tǒng)表中記錄的元數(shù)據(jù)的邏輯一致性，驗(yàn)證數(shù)據(jù)庫(kù)中所有索引試圖的內(nèi)容，檢測(cè)數(shù)據(jù)庫(kù)中的Service Broker數(shù)據(jù)等。

排除故障

找到了修復(fù)的方法后，執(zhí) 行“RESTORE DATABASE DBNAMEFROM= 'f:databakXXX.bak ' WITH CONTINUE_AFTER_ERROR”命令，執(zhí)行恢復(fù)操作，系統(tǒng)提示“Restore was successful but defered transactions remain. These transactions cannot be resolved because there are data that is unavailable”，“RESTORE WITH CONTINUE_AFTER_ERROR was successful but some damage was encountered,Inconsi stencies in the database are possible”，“RESTORE DATABASE successfully processes x pages in x seconds”等提示，說(shuō)明數(shù)據(jù)庫(kù)恢復(fù)順利完成。

之后該數(shù)據(jù)庫(kù)處于Suspect可疑狀態(tài)無(wú)法直接使用，執(zhí)行“ALTER CHECKDB DNNAME SET EMERGENCY”命令，將其設(shè)置為緊急狀態(tài)。執(zhí)行“DBCC CHECKDB(DBNAME)”，“DBCC CHECKED(DBNAME, REPAIR_ALLOW_DATA_LOSS)”命令進(jìn)行修復(fù)處理。

修復(fù)完成后，執(zhí)行“use dbname”，“select * from salestb”等命令，可以正常打開(kāi)并訪問(wèn)其中的數(shù)據(jù)表。經(jīng)過(guò)檢測(cè)，雖然丟失了少量數(shù)據(jù)，但是絕大部分?jǐn)?shù)據(jù)都還在，這對(duì)數(shù)據(jù)庫(kù)影響不大，至此數(shù)據(jù)恢復(fù)成功完成。

當(dāng)然，這里的緊急修復(fù)操作，只是無(wú)奈之舉，存在丟失數(shù)據(jù)甚至失敗的風(fēng)險(xiǎn)，因此在日常維護(hù)數(shù)據(jù)庫(kù)時(shí)，需要定期對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份和檢測(cè)，將風(fēng)險(xiǎn)降到最低。因?yàn)閱挝坏腟QL Server數(shù)據(jù)庫(kù)體積不大，所以執(zhí)行“DBCC CHECKDB”命令消耗的時(shí)間不長(zhǎng)，但是對(duì)于體積龐大的數(shù)據(jù)庫(kù)來(lái)說(shuō)，如果存在的問(wèn)題較多的話，修復(fù)起來(lái)就會(huì)極為耗時(shí)，同時(shí)，還會(huì)引起數(shù)據(jù)庫(kù)阻塞。