標籤:style blog color 使用 sp 檔案 資料 div on
作為資料庫管理員最最痛苦的莫過於,當資料庫宕機的時候需要找備份,但在這個時候突然發現備份檔案也是壞的,這就意味著資料會丟失,為此可能會丟掉職位,飯碗不保,所以為此,我們一定要保證好備份的完整性,一般發生這種情況的原因莫過於一下幾種:
1、備份檔案和資料庫放在同一個(或一組)的物理磁碟上。磁碟出現故障,備份也保不住了。
2、備份介質隨壞,或者做的是網路備份,資料在網路傳輸中發生了損壞。
3、資料庫在做完整備份、檔案備份或者檔案組備份的時候,裡面的內容就已經有了隨壞。
所以基於此,我們要避免的就是以上三種情況的發生,此外還有一種情況就是SQL Server在做Database Backup的時候為節省時間,基本只是很簡單的把資料頁面拷貝下來,不會做一致性檢查。但是在恢複的時候,需要將資料庫恢複(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_nameFROM 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參數將資料庫恢複到唯讀模式。可以將一些報表查詢工作轉移到備用機上,減輕生產伺服器的負擔。
總之,資料安全非常重要,災難恢復要求很短的資料庫,如果沒有鏡像技術的保證,待命伺服器非常必要的。
《SQL Server企業級平台管理實踐》讀書筆記——當我們的備份都已經損壞的時候該怎麼辦