任何數據庫系統都無法避免崩潰的狀況即使你使用了Clustered雙機熱備等等仍然無法完全根除系統中的單點故障何況對於大部分用戶來說無法承受這樣昂貴的硬件投資所以在系統崩潰的時候我們應該如何恢復原有的寶貴數據就成為一個極其重要的問題了
在恢復的時候最理想的情況就是你的數據文件和日志文件都完好無損了這樣只需要sp_attach_db把數據文件附加到新的數據庫上即可或者在停機的時候把所有數據文件（一定要有master等）都copy到原有路徑下也行不過一般不推薦這樣的做法sp_attach_db比較好雖然麻煩許多
但是呢一般數據庫崩潰的時候系統是未必能有時間把未完成的事務和髒頁等寫入磁盤的這樣的情況sp_attach_db就會失敗那麼寄希望於DBA制定了一個良好的災難恢復計劃吧按照你的恢復計劃還原最新的完全備份增量備份或者事務日志備份然後如果你的活動事務日志還能讀得出來的話恭喜你！你可以還原到崩潰前的狀態
一般的單位都是沒有專職的DBA的如果沒有可用的備份更可能是最近一次備份的時間過於久遠而導致不可接受的數據損失而且你的活動事務日志也處於不可用的狀態那就是最麻煩的情況了
不幸的很的是一般數據庫崩潰都是由於存儲子系統引起的而這樣的情況是幾乎不可能有可用的日志用於恢復的
那麼就只好試一下這些方案了當然是要求至少你的數據文件是存在的要是數據文件日志文件和備份都沒有了的話別找我你可以到樓頂上去唱神啊救救我吧
首先你可以試一下sp_attach_single_file_db試著恢復一下你的數據文件雖然能恢復的可能性不大不過假如這個數據庫剛好執行了一個checkpoint的話還是有可能成功的
如果你沒有好到有摸彩票的手氣最重要的數據庫沒有像你期盼的那樣attach上去不要氣餒還是有別的方案的
我們可以試著重新建立一個log先把數據庫設置為emergency modesysdatabases的status為 就表示數據庫處於此狀態
不過系統表是不能隨便改的設置一下先
Use Master
Go
sp_configure allow updates
reconfigure with override
Go
然後
update sysdatabases set status = where name =
現在祈求滿天神佛的保佑吧重新建立一個log文件成功的機會還是相當大的系統一般都會認可你新建立的日志如果沒有報告什麼錯誤現在就可以松一口氣了
雖然數據是恢復了可是別以為事情就算完成了正在進行的事務肯定是丟失了原來的數據也可能受到一些損壞
先把SQL Server 重新啟動一下然後檢查你的數據庫吧
[] []
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22414.html
