資料庫管理者最大的夢魇，莫過于已經做了備份，但是在想恢複的時候，發現備份檔案也是壞的。這将意味着資料庫的丢失，後果非常可怕。發生這種情況的原因一般有3個： · 備份檔案和資料庫放在同一個(或一組)實體硬碟上。硬碟出故障，備份也保不
資料庫管理者最大的夢魇，莫過于已經做了備份，但是在想恢複的時候，發現備份檔案也是壞的。這将意味着資料庫的丢失，後果非常可怕。發生這種情況的原因一般有3個：
· 備份檔案和資料庫放在同一個(或一組)實體硬碟上。硬碟出故障，備份也保不住。
· 備份媒體損壞；或者做的是網絡備份，資料在網絡傳輸中發生了損壞。
· 資料庫在做完整備份、檔案備份或者檔案組備份的時候，裡面的内容就已經有了損壞。
SQL Server在做資料備份的時候為了節省時間，基本隻是很簡單地把資料頁面拷貝下來，不會做一緻性檢查的。但是在恢複的時候，需要将資料庫恢複(Recover)到事務一緻的一個時間點。如果備份中的損壞妨礙了SQL Server的前滾後滾(Redo和Undo)，恢複動作就會遇到錯誤。
無論何種情況，您都可以：
· 修複硬體錯誤并重新嘗試還原操作。
· 忽略錯誤，繼續還原操作，并在還原完成後修複資料庫。
· 放棄還原操作，改用備用還原計劃。
在現實環境裡，能夠通過重試解決的問題還是比較少的。硬體錯誤往往會永久地損壞備份檔案裡的内容。在先前的SQLServer版本裡，管理者可能不得不嘗試去尋找更早的備份。這往往意味着有很多天的資料丢失，損失是比較大的。
SQL Server 資料庫恢複有一個“忽略錯誤”的功能，在這種為難的時刻可以發揮很大的作用。
忽略錯誤繼續執行操作
CONTINUE_AFTER_ERROR是恢複指令(RESTORE)裡面的一個選項。它将使還原操作跳過錯誤繼續進行，并還原SQL Server現在所能還原的所有内容。資料還原結束後，可以應用後續事務日志備份，将資料庫恢複。如果日志恢複時遇到錯誤，SQLServer會在日志中報告，并且不讓使用者通路和這些事務有關的頁面。資料庫将在盡可能的情況下聯機。是以大部分情況下，資料庫整體還是能恢複出來，隻是部分資料有可能會丢失。
資料丢失量取決于遇到的錯誤。例如，一般資料頁中的錯誤隻會引起該頁進入可疑狀态，但資料庫恢複還會繼續。有問題的頁面編号将被寫入磁盤并記錄到suspect_pages表和錯誤日志中，提醒管理者在恢複結束後繼續處理它們。如果不設定CONTINUE_AFTER_ERROR，SQL Server隻要遇到一個頁面有問題，整個恢複動作都會停止。
如果錯誤發生在一些比較關鍵的地方，比如某個資料檔案的檔案頭資訊，那麼恢複還是有可能完全失敗，資料庫無法恢複。是以這個方法隻供救急之用。不能保證每次使用的效果。使用WITHCONTINUE_AFTER_ERROR還原資料後，要檢查錯誤日志以了解有關錯誤的詳細資訊。
基本的RESTORE文法為：
RESTORE DATABASE database_name
FROM backup_deviceWITH CONTINUE_AFTER_ERROR,
[NORECOVERY ]
管理者可以在忽略錯誤繼續執行的還原順序結束時，使用DBCCCHECKDB修複資料庫。要使CHECKDB在使用RESTORECONTINUE_AFTER_ERROR後以最大的一緻性運作，建議在DBCC CHECKDB指令中使用WITH TABLOCK選項。在極個别情況下，可能沒有足夠的資訊來修複資料庫，CHECKDB也沒辦法修好資料庫，資料丢失将不可避免。不是說，有了RESTORE CONTINUE_AFTER_ERROR，備份壞掉也沒關系的。
建立備用(Standby)伺服器
CONTINUE_AFTER_ERROR隻不過是指令SQLServer跳過一切它能夠跳過的錯誤，将所有還能讀出來的資料恢複出來，進而最大程度地挽回資料。但是有些對資料一緻性要求比較高的系統，比如銀行賬戶系統，使用者可不接受“部分”資料恢複。對他們來講，資料不一緻可能就意味着錢已經從一個賬戶轉走，但是沒有進入另一個賬戶，這是不可接受的。是以他們甯可将資料庫恢複到昨天的狀态，把今天所有的操作重做一遍。
對于這樣的系統，在建立備份和選擇恢複政策的時候，就要考慮到最壞的情況，預先想好方案，将損失降到最低。
事先預備一台備用機，将做好的備份使用LogShipping或者其他類似的機制在備用伺服器上預先恢複好，是一個值得推薦的方法。這樣做的好處有：
(1)比起實體鏡像之類的技術，這種方案比較經濟。備用伺服器的硬體要求不高，隻要硬碟足夠大。
(2)雖然SQL Server提供了若幹備份校驗機制，但是確定備份完整可靠的唯一辦法是真正地去恢複它。
(3)提前恢複備份，使得在真正災難發生時，隻需要恢複最後一個日志備份即可，而不需要在火燒眉毛的時候，去等那個漫長的完整備份恢複，可以大大節約災難恢複時間。
(4)備用機上的資料庫雖然不能修改，但是可以使用STANDBY參數将資料庫恢複到隻讀模式。可以将一些報表查詢工作轉移到備用機上，減輕生産伺服器的負擔。
總之，資料安全非常重要，災難恢複時間要求很短的資料庫，如果沒有鏡像技術的保障，備用伺服器是非常必要的。
本條技術文章來源于網際網路，如果無意侵犯您的權益請點選此處回報版權投訴
本文系統來源：php中文網