今天接到客戶一個(gè)電話說前段時(shí)間購買的用友暢捷通T+V12.0專業(yè)版軟件出現(xiàn)了問題，報(bào)奇怪的錯(cuò)誤：8395數(shù)據(jù)庫錯(cuò)誤，根據(jù)以往的經(jīng)驗(yàn)，這種奇怪的數(shù)據(jù)庫代碼錯(cuò)誤一般首先是DBCC checkdb一下，看看有沒有數(shù)據(jù)庫一致性錯(cuò)誤或者分配錯(cuò)誤。
進(jìn)入 SQL2008R2 數(shù)據(jù)庫，使用DBCC CHECKDB 檢測(cè)了一下，發(fā)現(xiàn)出現(xiàn)了錯(cuò)誤，提示：系統(tǒng)表預(yù)檢查: 對(duì)象 ID 7。無法使用閂鎖類型 SH 讀取并閂鎖頁 (1:34440)。由于不可修復(fù)的錯(cuò)誤，CHECK 語句已終止。這個(gè)問題怎么辦呢？
語句：dbcc checkdb(UFTData26912_000111)
數(shù)據(jù)庫檢查后提示信息如下：
消息 7985，級(jí)別 16，狀態(tài) 2，第 1 行
系統(tǒng)表預(yù)檢查: 對(duì)象 ID 7。無法使用閂鎖類型 SH 讀取并閂鎖頁 (1:34440)。由于不可修復(fù)的錯(cuò)誤，CHECK 語句已終止。
UFTData26912_000111的 DBCC 結(jié)果。
消息 5233，級(jí)別 16，狀態(tài) 98，第 1 行
表錯(cuò)誤: 分配單元 ID 458752，頁 (1:34440)。測(cè)試(IS_OFF (BUF_IOERR, pBUF->bstat))失敗。值是 12716041 和 -6。
CHECKDB 發(fā)現(xiàn)有 0 個(gè)分配錯(cuò)誤和 1 個(gè)一致性錯(cuò)誤與任何單個(gè)的對(duì)象都沒有關(guān)聯(lián)。
CHECKDB 在數(shù)據(jù)庫 'UFTData26912_000111' 中發(fā)現(xiàn) 0 個(gè)分配錯(cuò)誤和 1 個(gè)一致性錯(cuò)誤。
1、首先用友小辣妹問了一下客戶是不是昨天到今天有異常關(guān)機(jī)的情況，客戶說昨晚出現(xiàn)過異常斷電，今天早上開機(jī)時(shí)還有檢測(cè)磁盤的那個(gè)提示，一開軟件就提示前面的錯(cuò)誤了？
2、這下不好辦了，斷電問題數(shù)據(jù)庫出現(xiàn)：無法使用閂鎖類型 SH 讀取并閂鎖頁，是非常難搞定的，先用用友數(shù)據(jù)庫置疑修復(fù)工具嘗試了一下，無效。
3、開始自己用語句進(jìn)行修復(fù)，大概嘗試了以下的一些辦法：
（1）使用常用語句進(jìn)行修復(fù)，操作語句和截圖如下，請(qǐng)大家參考：
alter database UFTData26912_000111 set emergency
alter database UFTData26912_000111 set single_user
dbcc checkdb('UFTData26912_000111',REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb('UFTData26912_000111',REPAIR_REBUILD)
--這條是修復(fù)表的語句，后面會(huì)用，現(xiàn)在不用執(zhí)行！dbcc checktable('UFTData26912_000111..ST_RDRecord',REPAIR_ALLOW_DATA_LOSS)
alter database UFTData26912_000111 set multi_user
結(jié)論：無效，仍然和之前的提示一樣，無法用語句修復(fù)了看來，不過用友財(cái)務(wù)軟件免費(fèi)下載網(wǎng)站并沒死心，再看看其他的招有沒有。
右擊數(shù)據(jù)庫的時(shí)候出現(xiàn)下面的提示，很明顯看出數(shù)據(jù)庫是存在問題的額：
（2）嘗試了一下查詢主要的表是什么情況，發(fā)下有問題，然后嘗試了單表修復(fù)，提示信息如下，仍然是修復(fù)不了。
消息 829，級(jí)別 21，狀態(tài) 1，第 1 行
數(shù)據(jù)庫 ID 9，頁 (1:34440) 已標(biāo)記為 RestorePending，可能表明磁盤已損壞。要從此狀態(tài)恢復(fù)，請(qǐng)執(zhí)行還原操作。
消息 5233，級(jí)別 16，狀態(tài) 98，第 1 行
表錯(cuò)誤: 分配單元 ID 458752，頁 (1:34440)。測(cè)試(IS_OFF (BUF_IOERR, pBUF->bstat))失敗。值是 12584969 和 -6。
消息 7985，級(jí)別 16，狀態(tài) 2，第 1 行
系統(tǒng)表預(yù)檢查: 對(duì)象 ID 7。無法使用閂鎖類型 SH 讀取并閂鎖頁 (1:34440)。由于不可修復(fù)的錯(cuò)誤，CHECK 語句已終止。
消息 829，級(jí)別 21，狀態(tài) 1，第 14 行
數(shù)據(jù)庫 ID 9，頁 (1:34440) 已標(biāo)記為 RestorePending，可能表明磁盤已損壞。要從此狀態(tài)恢復(fù)，請(qǐng)執(zhí)行還原操作。
（3）針對(duì)所有數(shù)據(jù)庫重建索引也是無效！
最終發(fā)現(xiàn)上述方法都沒有成功修復(fù)好數(shù)據(jù)，這種情況下只能采取下面的辦法了：
（1）查看有沒有自動(dòng)備份的數(shù)據(jù)，[好在 zzerp 這個(gè)客戶正好做了備份計(jì)劃，不過由于昨晚異常關(guān)機(jī)，只備份到前天的數(shù)據(jù)]跟客戶溝通了一下，客戶答應(yīng)補(bǔ)錄2天的數(shù)據(jù)。
用友軟件溫馨提醒：備份數(shù)據(jù)很重要，自動(dòng)備份最好每天設(shè)置2個(gè)時(shí)間點(diǎn)來備份。
（2）看看有多少表損壞，如果表太多損壞，基本上修復(fù)的可能性不大，如果有錢可以找數(shù)據(jù)修復(fù)公司，如果沒錢就只能補(bǔ)錄數(shù)據(jù)了。如果表損壞的較少，可以用數(shù)據(jù)庫導(dǎo)入導(dǎo)出工具導(dǎo)出表到新的數(shù)據(jù)庫里繼續(xù)使用（這種情況一般建議是只有總賬+報(bào)表模塊，如果模塊較多還是少用導(dǎo)表的方式。）
如有數(shù)據(jù)庫修復(fù)問題解決不了的，可以嘗試聯(lián)系我們的QQ：1820223520，寫明是找我進(jìn)行數(shù)據(jù)修復(fù)的，有償服務(wù)，非誠勿擾，具體價(jià)格看具體數(shù)據(jù)損壞程度進(jìn)行收費(fèi)?？上劝l(fā)用友軟件的賬套數(shù)據(jù)過來修復(fù)，修復(fù)好后再付款，沒修復(fù)好不收任何費(fèi)用。
