近日，用戶打電話請求技術支持，說素材采集數據庫連接不上，筆者在網管控制臺啟動應用程序，發現確實如此，如圖1。
筆者進行了簡單的測試：ping數據庫服務器沒有問題，證明網絡連接沒有問題。ODBC連接也可以連接到數據庫服務器的MASTER數據庫，證明客戶端沒有問題。問題應該出在CMS應用數據庫上。
直到現在筆者還沒有認識到問題的嚴重性，打開企業管理器，察看CMS數據庫的狀態，竟然是“置疑”！

 
圖1 錯誤信息

出現“置疑”狀態有幾種可能：
1、數據庫文件或者相關的日志文件丟失；
2、數據庫所在的路徑發生變化；
3、磁盤可用空間不足；
4、SQL Server可能沒有足夠的時間來恢復數據庫；
5、數據庫在數據寫入的過程中數據頁因為停電或者內存泄漏等操作被損壞。
為了查看故障情況，首先，重新啟動了數據庫服務器，察看SQL Server服務管理器中的SQL Server的運作狀況，發現其運行正常，說明SQL Server服務是正常的。打開企業管理器，故障情況依舊。
首先向部門領導報告了故障發生的情況，請示以后緊急啟用了一臺臨時服務器。
根據故障的狀況和“置疑”發生的可能性，筆者逐一進行了排查。文件路徑沒有改變，文件也沒有丟失，磁盤空間還有30GB，沒有進行數據庫恢復操作，那就只有最后一種可能了。問一下同事數據中心是否停過電，回答是沒有。仔細問了一下，有沒有異常發生，這時候有個同事說剛才在調試KVM的時候不小心把電源線給拔下來，由于沒有認識到是連接的服務器，連續接插了幾次，啊！這可是資料存儲的Server啊！不過還好，數據庫文件、日志文件還在，可以使用數據庫附加到服務器。打開查詢分析器輸入以下腳本命令：
EXEC sp_attach_db @dbname = N'cms',
@filename1 = N'd:\Data\cms.mdf',
@filename2 = N'e:\Data\cms_log.ldf'
如果數據庫文件沒有問題，這樣的話就應該OK了。因為文件很大，執行開始以后，筆者就離開機房回到座位上，耐心等待數據庫附加完成。不過，最不愿意看到的事情發生了，數據庫文件損壞，不是有效的數據庫文件頭，可以確認這是災難性的！還好，想到還有完整的數據備份機制，至少可以把損失降低到最低程度吧。