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

 
圖1 錯(cuò)誤信息

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