總結步驟如下：
1、檢測數據庫， 使用命令（Dbcc checkdb） 拿到數據庫后附加到本地 SQLserver 使其運行，打開(kāi)企業(yè)管理器，查看它。 同時(shí)打開(kāi)查詢(xún)分析器，在里面輸入Dbcc checkdb 檢測數據庫命令然后回車(chē) 即可以看到數據庫的分析資料看到問(wèn)題， 評注：拿到問(wèn)題先不要盲目的卸載 SQLServer，本次因為新手，上手后就把 數據庫卸載，這樣就耗費了一天的時(shí)間，過(guò)沒(méi)有任何作用，測試服務(wù)器的完整性 可以拿一個(gè)好的數據庫做對比，自己可以建一個(gè)“test”，如果測試數據庫運行 正常，則不需要對服務(wù)器做任何改動(dòng)。千萬(wàn)不要改動(dòng)系統，麻煩會(huì )更大。 提示：錯誤會(huì )以紅色顯示。
2、簡(jiǎn)單修復：命令：dbcc checkdb 輸入以下兩句嘗試修復。
DBCC CHECKDB('數據庫名',repair_allow_data_loss)
DBCC CHECKDB('數據庫名',repair_rebuild)
不管他究竟哪里錯了， 先用這兩句試試一般的索引系統文件丟失， SQLserver 都可以解決這個(gè)問(wèn)題，基本就差不多了。但是對于主鍵索引損壞，這個(gè)命令基本 修不好，所以對一個(gè)滿(mǎn)身是傷的數據庫，他可以修復 70%。
注：修復時(shí)系統提示必須要在單用戶(hù)模式下才可以生效，用戶(hù)可以去企業(yè)管 理器，對要修理的數據庫：右擊屬性-選項-限制訪(fǎng)問(wèn)-單用戶(hù)。也可以使用以下語(yǔ)句實(shí)現：
ALTER DATABASE 數據庫名 SET single_USER
GO
---改為單用戶(hù)
ALTER DATABASE 數據庫名 SET MULTI_USER
GO
---改為多用戶(hù)
繼續使用 dbcc checkdb 檢測，如果繼續報錯。 再次運行：
DBCC CHECKDB('DataBasename') with NO_INFOMSGS,PHYSICAL_ONLY
然后再運行：
DBCC CHECKDB(' DataBasename ',repair_allow_data_loss) WITH TABLOCK
再次運行:DBCC CHECKDB('DB name')
系統顯示修復成功，說(shuō)明本次問(wèn)題主 要由索引等數據庫系統本身問(wèn)題引起，這樣的修復可能會(huì )導致數據丟失，但是絕 對不會(huì )是大批丟失，基本沒(méi)有影響。
3、檢測表：命令：dbcc checktable(‘tablename’) 接上述檢測提示：我們可以看到一個(gè) id 號，這個(gè)基本就是這個(gè)錯誤的表在 系統表“sysobjects”里面的注冊信息。
輸入如下語(yǔ)句即可以看見(jiàn)：
select * from sysobjects where id=1205579333（錯誤提示號碼）
接下來(lái)檢測這張表究竟是什么問(wèn)題。 輸入：
dbcc checktable(‘tablename’)
接下來(lái)將會(huì )得到一些錯誤提示，基本上就是檢測表的時(shí)候那些，提示什么 B 樹(shù)錯誤， 父節點(diǎn)， 子節點(diǎn)錯誤， 這些都別管， 因為這個(gè)可能就是索引引起的錯誤：
嘗試用下列語(yǔ)句修復： DBCC CHECKtable('Tablename',repair_rebuild)
執行完后查看提示：如果出現下面的提示 CREATE UNIQUE INDEX 終止，因為發(fā)現了索引 ID 1 的重復鍵。最重要的主 鍵為 '3'。這里基本上就可以確定就是索引出的問(wèn)題，而且數據表沒(méi)有被修復的 可能很可能就是內容產(chǎn)生的問(wèn)題。根據提示，我們得出的結論就是主鍵重復。 這是我們使用 select 查詢(xún)語(yǔ)句是看不到的甚至表里面打開(kāi)也沒(méi)有反映。此時(shí)， 關(guān)閉查詢(xún)分析器， 打開(kāi)企業(yè)管理器， 找到那個(gè)數據表， 然后右擊選擇設計表， 選擇主鍵，右擊，取消主鍵，回到查詢(xún)分析器，找到該表，右擊選擇索引，這時(shí) 候表以前所有的索引都能看見(jiàn)了，但是上面的唯一性選項很明顯沒(méi)有了，然后給 表里面添加一個(gè)新的字段，字段名 id 需要生成編號：
語(yǔ)句如下：
alter table t_item add id integer identity
該字段用完后刪除，
語(yǔ)句如下：
alter table t_item drop column id
在查詢(xún)分析器這里右擊索引，選擇唯一性選項，然后點(diǎn)擊確定，系統會(huì )提示 重復鍵，和最重要的主鍵 ID，根據 id 數字，進(jìn)行查詢(xún) 如提示最重要的鍵值是 3 則， select * from t_item where fitemid=3 有時(shí)候查詢(xún)的結果，是合法的，比如這個(gè) 3 可能只有一條，這個(gè)時(shí)候，就右 擊索引，點(diǎn)擊編輯勾選唯一性，在列上面去掉一個(gè)，從上往下第一個(gè)開(kāi)始，但是 必須記住他的名字，最好寫(xiě)下來(lái)，這時(shí)候，你會(huì )發(fā)現錯誤信息里面的 ID 換成了 另外一個(gè)數字， 繼續用 select 語(yǔ)句查詢(xún)該數字， 字段仍然是該表的第一個(gè)字段， 你會(huì )發(fā)現他有兩條， 仔細對比這兩條， 什么都是一樣的， 每一個(gè)字段的值都一樣， 這顯然不符合邏輯，用剛才添加的 id 記錄刪除一條，
語(yǔ)句如下： Delete tablename where id=
兩著(zhù)任何一個(gè)，刪除完后， 右擊恢復剛才被點(diǎn)掉的那一條列名，勾選上唯一性，點(diǎn)擊確定，則正常，回 到企業(yè)管理器，打開(kāi)表設計，設置主鍵。完成。 回到查詢(xún)分析器，
輸入 dbcc checktable
顯示正常，再次檢測數據庫，顯 示正常。刪除剛才增加的列，修復完成。 結論：修復這類(lèi)數據表，別急著(zhù)導出數據，新建庫文件，這個(gè)應該還不到那 一步，最好就是能這樣修復，少動(dòng)干戈，如果是主鍵重復，你導出數據，在把這 個(gè)錯誤的數據倒進(jìn)來(lái)（這里假設能正常導入） ，表的錯誤會(huì )依然存在。
聯(lián)系客服
