IT工程師數位筆記本

作為數據庫管理員最最痛苦的莫過于，當數據庫宕機的時候需要找備份，但在這個時候突然發現備份文件也是壞的，這就意味著數據會丟失，為此可能會丟掉職位，飯碗不保，所以為此，我們一定要保證好備份的完整性，一般發生這種情況的原因莫過于一下幾種：

1、備份文件和數據庫放在同一個（或一組）的物理磁盤上。磁盤出現故障，備份也保不住了。

2、備份介質隨壞，或者做的是網絡備份，數據在網絡傳輸中發生了損壞。

3、數據庫在做完整備份、文件備份或者文件組備份的時候，里面的內容就已經有了隨壞。

所以基于此，我們要避免的就是以上三種情況的發生，此外還有一種情況就是SQL Server在做數據庫備份的時候為節省時間，基本只是很簡單的把數據頁面拷貝下來，不會做一致性檢查。但是在恢復的時候，需要將數據庫恢復（Recover）到事務一致性的一個時間點。如果備份中的損壞妨礙了SQL Server的前滾后滾（Redo和Undo）、恢復動作就會遇到錯誤，這時候我們該如何做呢？

其實在現實壞境中，遇到此問題大部分是硬件錯誤導致，但是該類錯誤往往會永久的隨壞備份文件里的內容，在SQL 2005之前的版本，遇到此問題只能去找更早的備份。但這就意味著會有產生很多的數據丟失。

所以在SQL 2005之后引入了一個新的“忽略錯誤”的恢復功能，這種情況在危難的是時候可以很好的發揮作用。

該命令為：CONTINUE_AFTER_ERROR

該命令是會恢復（RESTORE）命令里的一個新選項。它將使還原操作跳過錯誤繼續進行，并還原SQL Servr現有所有功能還原的所有內容。數據還原結束后，可以應用后續事務日志備份，將數據庫恢復。如果日志恢復時遇到錯誤，SQL Server會在日志中報告，并且不讓用戶訪問和操作這些事務有關的頁面。數據庫將在盡可能的情況相愛聯機。所以大部分情況下，數據庫整體還是能恢復出來，只是部分數據有可能會丟失。

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

如果錯誤發生在一些比較關鍵的地方，比如某個數據文件的文件頭信息，那么恢復還是有可能完全失敗，數據庫無法恢復。所有這個方法只供救火的時候用，不能保證每次使用的效果。

在使用該命令完成還原數據庫后，記得要檢查錯誤日志以了解有關的詳細信息。

該命令語法如下：

RESTORE DATABASE database_name
FROM backup device WITH CONTINUE_AFTER_ERROR,NORECOVERY....

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

其實最關鍵的是還是建立備用服務器，改變單一磁盤的尷尬。

CONTINUE_AFTER_ERROR只不過是通過命令跳過一切它能夠跳過錯誤，將所有還能讀出來的數據恢復出來，從而最大程度的挽回數據。但是有些數據對一致性要求比較高的系統這樣是不能接受的。

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

可以找一臺備用機，做Log Shipping，這個方法值得推薦，主要是成本低

有以下幾點優點：

1、比起物理鏡像之類的技術，這種方案比較經濟。備用服務硬件的要求不高，只要硬盤足夠大。

2、雖然SQL Server提供了若干備份校驗機制，但是確保備份完整可靠性的唯一辦法就是真正的去恢復它。

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

4、備用機上的數據庫雖然不能修改，但是可以使用standby參數將數據庫恢復到只讀模式。可以將一些報表查詢工作轉移到備用機上，減輕生產服務器的負擔。

總之，數據安全非常重要，災難恢復時間要求很短的數據庫，如果沒有鏡像技術的保證，備用服務器非常必要的。