參加數據庫管理工作，已經一年了。這一年裏憑藉自己的努力，解決了一個又一個的問題，從中也長大了不少。
記得去年5月那次，數據庫服務器突然壞掉（操作系統出問題了），再也無法啟動。後來增加了一個新硬盤，安裝了新系統才得以正常啟動。
本以為數據庫文件都還在原來的地方，只要附加過來就沒有什麼問題了。把數據庫安裝好之後，也如我所想，順利的附加上了其餘的7個庫。但好運並沒有光顧我，最重要的數據庫附加時報錯了。這下可把我極壞了，可笑的是這個數據庫的備份既然被清空了。無奈之下，只有使用DBCC CHECKDB來嘗試，我心裡很明白，如果這個命令無效的話，就是宣告這個數據庫完蛋了。這麼多年的數據毀於一旦。
我還是幸運的，最終通過命令終於修復完成。數據庫正常使用，具體的出錯頁面被刪除。
我主要使用的辦法如下：
1、建一個與原數據庫一樣名字的新的空數據庫，文件的命名（data文件和日誌文件）必須和原來一致。把數據庫服務停掉，然後把數據文件（發生錯誤的那個）覆蓋剛建好的同名數據庫文件。
2、啟動數據庫服務。發現該數據庫置疑狀態。
3、把數據庫置為緊急狀態：alter database 數據庫名set emergency（此時的數據庫可以讀，但不可以寫）如果實在還原不了，可以在緊急狀態導出數據。
4、接下來修改數據庫為單用戶（不知道不設但用戶行不行，我沒有試過）。alter database bsmaster set single_user
5、執行DBCC CHECKDN命令（關鍵一步，此處失敗就沒戲了）。dbcc checkdb('數據庫名',REPAIR_ALLOW_DATA_LOSS)
6、等待命令結果。如果成功則數據庫置為在線，但是為單用戶模式。此時只要修改成多用戶即可。如果失敗，就只能還原數據庫。
這個是我遇到眾多的問題中的一個。我解決了，但是我並沒有開心，沒有備份的管理員，是走上絕路管理員。從那開始我對備份特別關注，對與每個備份我都認真的去檢查，我不會讓悲劇重演的。
