server|恢複|資料|資料庫
任何資料庫系統都無法避免崩潰的狀況,即使你使用了Clustered,雙機熱備……仍然無法完全根除系統中的單點故障,何況對於大部分使用者來說,無法承受這樣昂貴的硬體投資。
所以,在系統崩潰的時候,如何恢複原有的寶貴資料就成為一個極其重要的問題了。
在恢複的時候,最理想的情況就是你的資料檔案和記錄檔都完好無損了,這樣只需要sp_attach_db,把資料檔案附加到新的資料庫上即可,或者在停機的時候把所有資料檔案(一定要有master等)都copy到原有路徑下也行,不過一般不推薦這樣的做法,sp_attach_db比較好,雖然麻煩許多。
但是呢,一般資料庫崩潰的時候系統是未必能有時間把未完成的事務和髒頁等寫入磁碟的,這樣的情況sp_attach_db就會失敗。那麼,寄期望於DBA制定了一個良好的災難恢複計劃吧。按照你的恢複計劃,還原最新的完全備份,增量備份或者交易記錄備份,然後如果你的活動交易記錄還能讀得出來的話,恭喜你!你可以還原到崩潰前的狀態。
一般的單位都是沒有專職的DBA的,如果沒有可用的備份,更可能是最近一次備份的時間過於久遠而導致不可接受的資料損失,而且你的活動交易記錄也處於停用狀態,那就是最麻煩的情況了。
不幸的很的是,一般資料庫崩潰都是由於儲存子系統引起的,而這樣的情況是幾乎不可能有可用的日誌用於恢複的。
那麼就只好試一下這些方案了。當然,是要求至少你的資料檔案是存在的,要是資料檔案、記錄檔和備份都沒有了的話,別找我,你可以到樓頂上去唱“神啊,救救我吧”。
首先,你可以試一下sp_attach_single_file_db,試著恢複一下你的資料檔案,雖然能恢複的可能性不大,不過假如這個資料庫剛好執行了一個checkpoint的話,還是有可能成功的。
如果你沒有好到有摸彩票的手氣,最重要的資料庫沒有像你期盼的那樣attach上去,不要氣餒,還是有別的方案的。
我們可以試著重建立立一個log,先把資料庫設定為emergency mode,sysdatabases的status為32768就表示資料庫處於此狀態。
不過系統資料表是不能隨便改的,設定一下先
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
然後
update sysdatabases set status = 32768 where name = ''
現在,祈求滿天神佛的保佑吧,重建立立一個log檔案。成功的機會還是相當大的,系統一般都會認可你建立立的日誌。如果沒有報告什麼錯誤,現在就可以鬆一口氣了。
雖然資料是恢複了,可是別以為事情就算完成了,進行中的事務肯定是丟失了,原來的資料也可能受到一些損壞。
先把SQL Server 重新啟動一下,然後檢查你的資料庫吧。
先設定成單一使用者模式,然後做dbcc
sp_dboption '', 'single user', 'true'
DBCC CHECKDB('')
如果沒有什麼大問題就可以把資料庫狀態改回去了,記得別忘了把系統資料表的修改選項關掉。
update sysdatabases set status = 28 where name = ''
--當然你的資料庫狀態可能不是這個,自己改為合適的值吧。也可以用sp_resetstatus
go
sp_configure 'allow updates', 0
reconfigure with override
Go
checkdb的時候可能報告有一些錯誤,這些錯誤的資料你可能就只好丟棄了。
checkdb有幾種修複選項,自己看著用吧,不過最後你可能還是得用REPAIR_ALLOW_DATA_LOSS,完成所有修複。
chekcdb並不能完成所有的修複,我們需要更進一步的修複,用DBCC CHECKTABLE對每一個表做檢查吧。
表的列表可以用sysobjects裡面得到,把OBJECTPROPERTY是IsTable的全部找出來檢查一下吧,這樣能夠基本上解決問題了,如果還報告錯誤,試著把資料select into到另一張表檢查一下。
這些都做完了之後,把所有索引、視圖、預存程序、觸發器等重建立立一下。DBCC DBREINDEX也許可以幫你一些忙。
然後,就可以向boss吹噓一下你的豐功偉業,順便小小的提一下加薪的要求,如果(很有可能)不得逞的話,也只好回家睡覺去:'(
記得下次別忘了做好備份哦~
上面提到的命令、對象在Books Online中均有詳細說明,請注意參看。