標籤：
快速修複
DBCC CHECKDB (‘資料庫名‘, REPAIR_FAST)
重建索引並修複
DBCC CHECKDB (‘資料庫名‘, REPAIR_REBUILD)
如果必要允許遺失資料修複
DBCC CHECKDB (‘資料庫名‘‘, REPAIR_ALLOW_DATA_LOSS)如果出現錯誤：未處理修複語句。資料庫需處於單一使用者模式下。可以先啟用單一使用者模式，方法如下執行預存程序：Use master
go
sp_dboption 資料庫名, single, true--更改成單使用者
alter database 資料庫名 set single_user with rollback immediate --還原資料庫為多使用者模式
alter database 資料庫名 set multi_user with rollback immediate手工修複資料庫試例操作步驟:----------------------------------------------------------------------------------------------
進入SQL查詢分析器,執行語句: --檢查資料庫完整性
dbcc checkdb(‘資料庫名‘) 執行結果:
---------------------------------------------------------------
CHECKDB 發現了 0 個分配錯誤和 11 個一致性錯誤（在資料庫 ‘ams1‘ 中）。
repair_allow_data_loss 是最低的修複層級（對於由 DBCC CHECKDB (資料庫名) 發現的錯誤而言）。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。
說明資料庫確實有問題,11個錯誤,找到錯誤地方:-------------------------------------------------------------------------------
對象 ‘Tb_Archives_File_1‘ 有 3777 行，這些行位於 172 頁中。
CHECKDB 發現了 0 個分配錯誤和 2 個一致性錯誤（在表 ‘Tb_Archives_File_1‘ 中，該表的物件識別碼 為 907150277）。 表明 ‘Tb_Archives_File_1‘ 表確實有2個錯誤,難怪一查詢就要死機,於是運行語句進行表修複:--------------------------------------------------------------------------------------
--以repair_allow_data_loss層級修複表
dbcc checktable(‘Tb_Archives_File_1‘,repair_allow_data_loss)
go 執行結果:
伺服器: 訊息 7919，層級 16，狀態 3，行 2
未處理修複語句。資料庫需要處於單一使用者模式下。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊，請與系統管理員聯絡。 --------------------------------------------------------------------------------------------------- 需要將資料庫改為"單一使用者模式",於是再執行:
--更改成單使用者
alter database 資料庫名 set single_user with rollback immediate
go
--已repair_allow_data_loss層級修複表
dbcc checktable(‘Tb_Archives_File_1‘,repair_allow_data_loss)
go
--若還有問題，修複索引表
DBCC DBREINDEX(‘Tb_Archives_File_1‘) --再修複表
DBCC CHECKTABLE(‘Tb_Archives_File_1‘) 直到返回的結果沒有錯誤! --查詢是否正常
select * from Tb_Archives_File_1 再查詢那張錯誤表,不報錯,也不死機了,資料也完好無損.....哈哈.... --還原資料庫為多使用者模式
alter database 資料庫名 set multi_user with rollback immediate 轉自：http://blog.csdn.net/zhejingyuan/article/details/11681865
DBCC CHECKDB用法 手工修複資料庫
