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

 
圖1 錯誤信息

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