任何資料庫系統都無法避免崩潰的狀況，即使你使用了Clustered，雙機熱備……仍然無法完全根除系統中的單點故障，何况對於大部分用戶來說，無法承受這樣昂貴的硬體投資。 所以，在系統崩潰的時候，如何恢復原有的寶貴數據就成為一個極其重要的問題了。
在恢復的時候，最理想的情况就是你的資料檔案和日誌檔都完好無損了，這樣只需要sp_attach_db，把資料檔案附加到新的資料庫上即可，或者在停機的時候把所有資料檔案（一定要有master等）都copy到原有路徑下也行，不過一般不推薦這樣的做法，sp_attach_db比較好，雖然麻煩許多。
但是呢，一般資料庫崩潰的時候系統是未必能有時間把未完成的事務和髒頁等寫入磁片的，這樣的情况sp_attach_db就會失敗。 那麼，寄期望於DBA製定了一個良好的災難恢復計畫吧。 按照你的恢復計畫，還原最新的完全備份，增量備份或者事務日誌備份，然後如果你的活動事務日誌還能讀得出來的話，恭喜你！ 你可以還原到崩潰前的狀態。< br> 一般的組織都是沒有專職的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檔案。 成功的機會還是相當大的，系統一般都會認可你新建立的日誌。 如果沒有報告什麼錯誤，現在就可以松一口氣了。< br> 雖然數據是恢復了，可是別以為事情就算完成了，正在進行的事務肯定是遺失了，原來的數據也可能受到一些損壞。
先把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也許可以幫你一些忙。