SQLserver2000數據庫修複辦法總結
總結步驟如下：
1、檢測數據庫， 使用命令（Dbcc checkdb） 拿到數據庫後附加到本地 SQLserver 使其運行，打開企業管理器，查看它。 同時打開查詢分析器，在裡面輸入Dbcc checkdb 檢測數據庫命令然後回車 即可以看到數據庫的分析資料看到問題， 評注：拿到問題先不要盲目的卸載 SQLServer，本次因為新手，上手後就把 數據庫卸載，這樣就耗費了一天的時間，過沒有任何作用，測試服務器的完整性 可以拿一個好的數據庫做對比，自己可以建一個“test”，如果測試數據庫運行 正常，則不需要對服務器做任何改動。千萬不要改動系統，麻煩會更大。 提示：錯誤會以紅色顯示。
2、簡單修複：命令：dbcc checkdb 輸入以下兩句嘗試修複。
DBCC CHECKDB('數據庫名',repair_allow_data_loss)
DBCC CHECKDB('數據庫名',repair_rebuild)
不管他究竟哪裡錯了， 先用這兩句試試一般的索引系統文件丢失， SQLserver 都可以解決這個問題，基本就差不多了。但是對于主鍵索引損壞，這個命令基本 修不好，所以對一個滿身是傷的數據庫，他可以修複 70%。
注：修複時系統提示必須要在單用戶模式下才可以生效，用戶可以去企業管 理器，對要修理的數據庫：右擊屬性-選項-限制訪問-單用戶。也可以使用以下語句實現：
ALTER DATABASE 數據庫名 SET single_USER
GO
---改為單用戶
ALTER DATABASE 數據庫名 SET MULTI_USER
GO
---改為多用戶
繼續使用 dbcc checkdb 檢測，如果繼續報錯。 再次運行：
DBCC CHECKDB('DataBasename') with NO_INFOMSGS,PHYSICAL_ONLY
然後再運行：
DBCC CHECKDB(' DataBasename ',repair_allow_data_loss) WITH TABLOCK
再次運行:DBCC CHECKDB('DB name')
系統顯示修複成功，說明本次問題主 要由索引等數據庫系統本身問題引起，這樣的修複可能會導緻數據丢失，但是絕 對不會是大批丢失，基本沒有影響。
3、檢測表：命令：dbcc checktable(‘tablename’) 接上述檢測提示：我們可以看到一個 id 号，這個基本就是這個錯誤的表在 系統表“sysobjects”裡面的注冊信息。
輸入如下語句即可以看見：
select * from sysobjects where id=1205579333（錯誤提示号碼）
接下來檢測這張表究竟是什麼問題。 輸入：
dbcc checktable(‘tablename’)
接下來将會得到一些錯誤提示，基本上就是檢測表的時候那些，提示什麼 B 樹錯誤， 父節點， 子節點錯誤， 這些都别管， 因為這個可能就是索引引起的錯誤：
嘗試用下列語句修複： DBCC CHECKtable('Tablename',repair_rebuild)
執行完後查看提示：如果出現下面的提示 CREATE UNIQUE INDEX 終止，因為發現了索引 ID 1 的重複鍵。最重要的主 鍵為 '3'。這裡基本上就可以确定就是索引出的問題，而且數據表沒有被修複的 可能很可能就是内容産生的問題。根據提示，我們得出的結論就是主鍵重複。 這是我們使用 select 查詢語句是看不到的甚至表裡面打開也沒有反映。此時， 關閉查詢分析器， 打開企業管理器， 找到那個數據表， 然後右擊選擇設計表， 選擇主鍵，右擊，取消主鍵，回到查詢分析器，找到該表，右擊選擇索引，這時 候表以前所有的索引都能看見了，但是上面的唯一性選項很明顯沒有了，然後給 表裡面添加一個新的字段，字段名 id 需要生成編号：
語句如下：
alter table t_item add id integer identity
該字段用完後删除，
語句如下：
alter table t_item drop column id
在查詢分析器這裡右擊索引，選擇唯一性選項，然後點擊确定，系統會提示 重複鍵，和最重要的主鍵 ID，根據 id 數字，進行查詢 如提示最重要的鍵值是 3 則， select * from t_item where fitemid=3 有時候查詢的結果，是合法的，比如這個 3 可能隻有一條，這個時候，就右 擊索引，點擊編輯勾選唯一性，在列上面去掉一個，從上往下第一個開始，但是 必須記住他的名字，最好寫下來，這時候，你會發現錯誤信息裡面的 ID 換成了 另外一個數字， 繼續用 select 語句查詢該數字， 字段仍然是該表的第一個字段， 你會發現他有兩條， 仔細對比這兩條， 什麼都是一樣的， 每一個字段的值都一樣， 這顯然不符合邏輯，用剛才添加的 id 記錄删除一條，
語句如下： Delete tablename where id=
兩着任何一個，删除完後， 右擊恢複剛才被點掉的那一條列名，勾選上唯一性，點擊确定，則正常，回 到企業管理器，打開表設計，設置主鍵。完成。 回到查詢分析器，
輸入 dbcc checktable
顯示正常，再次檢測數據庫，顯 示正常。删除剛才增加的列，修複完成。 結論：修複這類數據表，别急着導出數據，新建庫文件，這個應該還不到那 一步，最好就是能這樣修複，少動幹戈，如果是主鍵重複，你導出數據，在把這 個錯誤的數據倒進來（這裡假設能正常導入） ，表的錯誤會依然存在。
最新文章
-
風雷打闆：宜昌“瑞鶴仙”打闆思路解密
4分鐘前 -
如何做趨勢交易
4分鐘前 -
教師基本功（39）：教師相互聽課究竟應聽什麼
4分鐘前 -
經絡治療咽喉炎
4分鐘前 -
釣魚人都會準備的靈丹妙藥，多少人隻知其一不知其二
4分鐘前 -
家裡各個房間的重要風水禁忌，好好檢查一下家裡的風水！
7分鐘前 -
不管是新手，還是老司機，這些汽車安全知識，一定要牢記！
25分鐘前 -
一場持續29年的求婚：英拉為何不願點頭孩子他爸為何不是她丈夫
40分鐘前
熱門文章
-
威士忌高階關于 OB 與 IB，一次給你說透！
7小時前 -
每日一誦傷寒論第241條
1周前 -
老張老李侃門球之140篇
2天前 -
這個穴位可以治療多種胃痛腹痛，還可以減肥
6天前 -
診餘雜記（師傳經驗）
4天前 -
美麗中國-2870：中國最大的内陸河，塔裡木河
2天前 -
為什麼五點鐘要起床答案讓人吃驚！（現在知道還不晚）
1周前 -
治療坐骨神經痛藥酒５方
1周前
有話要說...