數(shù)據(jù)庫備份與恢復(fù)之七應(yīng)對由于備份損壞導(dǎo)致的還原錯誤

數(shù)據(jù)庫管理員最大的夢魘，莫過于已經(jīng)做了備份，但是在想恢復(fù)的時候，發(fā)現(xiàn)備份文件也是壞的。這將意味著數(shù)據(jù)庫的丟失，后果非?？膳?。發(fā)生這種情況的原因一般有3個： · 備份文件和數(shù)據(jù)庫放在同一個（或一組）物理硬盤上。硬盤出故障，備份也保不

數(shù)據(jù)庫管理員最大的夢魘，莫過于已經(jīng)做了備份，但是在想恢復(fù)的時候，發(fā)現(xiàn)備份文件也是壞的。這將意味著數(shù)據(jù)庫的丟失，后果非常可怕。發(fā)生這種情況的原因一般有3個：

· 備份文件和數(shù)據(jù)庫放在同一個（或一組）物理硬盤上。硬盤出故障，備份也保不住。

· 備份介質(zhì)損壞；或者做的是網(wǎng)絡(luò)備份，數(shù)據(jù)在網(wǎng)絡(luò)傳輸中發(fā)生了損壞。

· 數(shù)據(jù)庫在做完整備份、文件備份或者文件組備份的時候，里面的內(nèi)容就已經(jīng)有了損壞。
SQL Server在做數(shù)據(jù)備份的時候為了節(jié)省時間，基本只是很簡單地把數(shù)據(jù)頁面拷貝下來，不會做一致性檢查的。但是在恢復(fù)的時候，需要將數(shù)據(jù)庫恢復(fù)（Recover）到事務(wù)一致的一個時間點。如果備份中的損壞妨礙了SQL Server的前滾后滾(Redo和Undo)，恢復(fù)動作就會遇到錯誤。

無論何種情況，您都可以：

· 修復(fù)硬件錯誤并重新嘗試還原操作。

· 忽略錯誤，繼續(xù)還原操作，并在還原完成后修復(fù)數(shù)據(jù)庫。

· 放棄還原操作，改用備用還原計劃。

在現(xiàn)實環(huán)境里，能夠通過重試解決的問題還是比較少的。硬件錯誤往往會永久地?fù)p壞備份文件里的內(nèi)容。在先前的SQLServer版本里，管理員可能不得不嘗試去尋找更早的備份。這往往意味著有很多天的數(shù)據(jù)丟失，損失是比較大的。

SQL Server 數(shù)據(jù)庫恢復(fù)有一個“忽略錯誤”的功能，在這種為難的時刻可以發(fā)揮很大的作用。

忽略錯誤繼續(xù)執(zhí)行操作

CONTINUE_AFTER_ERROR是恢復(fù)命令（RESTORE）里面的一個選項。它將使還原操作跳過錯誤繼續(xù)進(jìn)行，并還原SQL Server現(xiàn)在所能還原的所有內(nèi)容。數(shù)據(jù)還原結(jié)束后，可以應(yīng)用后續(xù)事務(wù)日志備份，將數(shù)據(jù)庫恢復(fù)。如果日志恢復(fù)時遇到錯誤，SQLServer會在日志中報告，并且不讓用戶訪問和這些事務(wù)有關(guān)的頁面。數(shù)據(jù)庫將在盡可能的情況下聯(lián)機(jī)。所以大部分情況下，數(shù)據(jù)庫整體還是能恢復(fù)出來，只是部分?jǐn)?shù)據(jù)有可能會丟失。

數(shù)據(jù)丟失量取決于遇到的錯誤。例如，一般數(shù)據(jù)頁中的錯誤只會引起該頁進(jìn)入可疑狀態(tài)，但數(shù)據(jù)庫恢復(fù)還會繼續(xù)。有問題的頁面編號將被寫入磁盤并記錄到suspect_pages表和錯誤日志中，提醒管理員在恢復(fù)結(jié)束后繼續(xù)處理它們。如果不設(shè)置CONTINUE_AFTER_ERROR，SQL Server只要遇到一個頁面有問題，整個恢復(fù)動作都會停止。

如果錯誤發(fā)生在一些比較關(guān)鍵的地方，比如某個數(shù)據(jù)文件的文件頭信息，那么恢復(fù)還是有可能完全失敗，數(shù)據(jù)庫無法恢復(fù)。所以這個方法只供救急之用。不能保證每次使用的效果。使用WITHCONTINUE_AFTER_ERROR還原數(shù)據(jù)后，要檢查錯誤日志以了解有關(guān)錯誤的詳細(xì)信息。

基本的RESTORE語法為：

RESTORE DATABASE database_name

FROM backup_deviceWITH CONTINUE_AFTER_ERROR, [NORECOVERY ]

管理員可以在忽略錯誤繼續(xù)執(zhí)行的還原順序結(jié)束時，使用DBCCCHECKDB修復(fù)數(shù)據(jù)庫。要使CHECKDB在使用RESTORECONTINUE_AFTER_ERROR后以最大的一致性運行，建議在DBCC CHECKDB命令中使用WITH TABLOCK選項。在極個別情況下，可能沒有足夠的信息來修復(fù)數(shù)據(jù)庫，CHECKDB也沒辦法修好數(shù)據(jù)庫，數(shù)據(jù)丟失將不可避免。不是說，有了RESTORE CONTINUE_AFTER_ERROR，備份壞掉也沒關(guān)系的。

建立備用（Standby）服務(wù)器

CONTINUE_AFTER_ERROR只不過是命令SQLServer跳過一切它能夠跳過的錯誤，將所有還能讀出來的數(shù)據(jù)恢復(fù)出來，從而最大程度地挽回數(shù)據(jù)。但是有些對數(shù)據(jù)一致性要求比較高的系統(tǒng)，比如銀行賬戶系統(tǒng)，用戶可不接受“部分”數(shù)據(jù)恢復(fù)。對他們來講，數(shù)據(jù)不一致可能就意味著錢已經(jīng)從一個賬戶轉(zhuǎn)走，但是沒有進(jìn)入另一個賬戶，這是不可接受的。所以他們寧可將數(shù)據(jù)庫恢復(fù)到昨天的狀態(tài)，把今天所有的操作重做一遍。

對于這樣的系統(tǒng)，在建立備份和選擇恢復(fù)策略的時候，就要考慮到最壞的情況，預(yù)先想好方案，將損失降到最低。

事先預(yù)備一臺備用機(jī)，將做好的備份使用LogShipping或者其他類似的機(jī)制在備用服務(wù)器上預(yù)先恢復(fù)好，是一個值得推薦的方法。這樣做的好處有：

（1）比起物理鏡像之類的技術(shù)，這種方案比較經(jīng)濟(jì)。備用服務(wù)器的硬件要求不高，只要硬盤足夠大。

（2）雖然SQL Server提供了若干備份校驗機(jī)制，但是確保備份完整可靠的唯一辦法是真正地去恢復(fù)它。

（3）提前恢復(fù)備份，使得在真正災(zāi)難發(fā)生時，只需要恢復(fù)最后一個日志備份即可，而不需要在火燒眉毛的時候，去等那個漫長的完整備份恢復(fù)，可以大大節(jié)約災(zāi)難恢復(fù)時間。

（4）備用機(jī)上的數(shù)據(jù)庫雖然不能修改，但是可以使用STANDBY參數(shù)將數(shù)據(jù)庫恢復(fù)到只讀模式?？梢詫⒁恍﹫蟊聿樵児ぷ鬓D(zhuǎn)移到備用機(jī)上，減輕生產(chǎn)服務(wù)器的負(fù)擔(dān)。

總之，數(shù)據(jù)安全非常重要，災(zāi)難恢復(fù)時間要求很短的數(shù)據(jù)庫，如果沒有鏡像技術(shù)的保障，備用服務(wù)器是非常必要的。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com