DBCC 數據庫錯誤檢查與修復

對數據庫運行 DBCC CHECKALLOC。
對數據庫中的每個表和視圖運行 DBCC CHECKTABLE。
對數據庫運行 DBCC CHECKCATALOG。
驗證數據庫中每個索引視圖的內容。
使用 FILESTREAM 在文件系統中存儲 varbinary(max) 數據時，驗證表元數據和文件系統目錄和文件之間的鏈接級一致性。
驗證數據庫中的 Service Broker 數據。
這意味著不必從 DBCC CHECKDB 單獨運行 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG 命令。有關這些命令執行的檢查的詳細信息，請參閱這些命令的說明。

Transact-SQL 語法約定

語法

復制

DBCC CHECKDB
[ [ ( database_name | database_id | 0 [ , NOINDEX | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ] ) ] [ WITH { [ ALL_ERRORMSGS ] [ , EXTENDED_LOGICAL_CHECKS ] [ , NO_INFOMSGS ] [ , TABLOCK ] [ , ESTIMATEONLY ] [ , { PHYSICAL_ONLY | DATA_PURITY } ] } ]
]

參數 database_name | database_id | 0
要為其運行完整性檢查的數據庫的名稱或 ID。如果未指定，或者指定為 0，則使用當前數據庫。數據庫名稱必須符合有關標識符的規則。

NOINDEX
指定不應對用戶表的非聚集索引執行會占用很大系統開銷的檢查。這將減少總執行時間。NOINDEX 不影響系統表，因為總是對系統表索引執行完整性檢查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKDB 修復發現的錯誤。指定的數據庫必須處于單用戶模式，才能使用以下修復選項之一。

REPAIR_ALLOW_DATA_LOSS
嘗試修復報告的所有錯誤。這些修復可能會導致一些數據丟失。

REPAIR_FAST
保留該語法只是為了向后兼容。未執行修復操作。

REPAIR_REBUILD
執行不會丟失數據的修復。這包括快速修復（如修復非聚集索引中缺少的行）以及更耗時的修復（如重新生成索引）。

REPAIR_REBUILD 不修復涉及 FILESTREAM 數據的錯誤。

重要提示：

僅將 REPAIR 選項作為最后手段使用。若要修復錯誤，建議您通過備份進行還原。修復操作不會考慮表本身或表之間可能存在的任何約束。如果指定的表與一個或多個約束有關，建議您在修復操作后運行 DBCC CHECKCONSTRAINTS。如果必須使用 REPAIR，則運行不帶有修復選項的 DBCC CHECKDB 來查找要使用的修復級別。如果使用 REPAIR_ALLOW_DATA_LOSS 級別，則建議您在運行帶有此選項的 DBCC CHECKDB 之前備份數據庫。

ALL_ERRORMSGS
顯示針對每個對象報告的所有錯誤。在 SQL Server 2008 Service Pack 1 (SP1) 中，默認情況下顯示所有錯誤消息。指定或省略此選項都不起作用。在 SQL Server 的早期版本（SQL Server 2005 SP3 除外）中，如果未指定 ALL_ERRORMSGS，則只為每個對象顯示前 200 條錯誤消息。按對象 ID 對錯誤消息排序，從 tempdb 數據庫生成的那些消息除外。

在 SQL Server Management Studio 中，返回的最大錯誤消息數為 1000。使用 Management Studio 時，如果指定了 ALL_ERRORMSGS，則可能需要多次執行 DBCC CHECKDB 才能得到完整的錯誤列表。當您指定 ALL_ERRORMSGS 時，我們建議您使用 sqlcmd 實用工具來執行 DBCC 命令，或計劃 SQL Server 代理作業來執行該命令并將輸出定向到文件。這兩種方法中的任一種都可以確保執行該命令一次即可報告所有錯誤消息。

EXTENDED_LOGICAL_CHECKS
如果兼容級別為 100 (SQL Server 2008) 或更高，則對索引視圖、XML 索引和空間索引（如果存在）執行邏輯一致性檢查。

有關詳細信息，請參閱本主題后面“備注”部分中的“對索引執行邏輯一致性檢查”。

NO_INFOMSGS
取消顯示所有信息性消息。

TABLOCK
使 DBCC CHECKDB 獲取鎖，而不使用內部數據庫快照。這包括一個短期數據庫排他 (X) 鎖。TABLOCK 可使 DBCC CHECKDB 在負荷較重的數據庫上運行得更快，但 DBCC CHECKDB 運行時會減少數據庫上可獲得的并發性。有關鎖的詳細信息，請參閱鎖模式。

TABLOCK 限制執行的檢查；DBCC CHECKCATALOG 未對數據庫運行并且 Service Broker 數據未進行驗證。

ESTIMATEONLY
顯示運行包含所有其他指定選項的 DBCC CHECKDB 時所需的 tempdb 空間估計數量。不執行實際數據庫檢查。

PHYSICAL_ONLY
將檢查限制為頁和記錄標頭的物理結構完整性、B 樹的物理結構以及數據庫的分配一致性。設計該檢查是為了以較小的開銷檢查數據庫的物理一致性，但它還可以檢測會危及用戶數據安全的殘缺頁、校驗和錯誤以及常見的硬件故障。

DBCC CHECKDB 完成運行所需的時間可能比早期版本要長得多。出現此現象的原因是：

邏輯檢查更加全面。
要檢查的某些基礎結構更為復雜。
引入了許多新的檢查以包含新增功能。
因此，使用 PHYSICAL_ONLY 選項可能會大幅減少對較大數據庫運行 DBCC CHECKDB 所需的時間，所以對需要頻繁檢查的生產系統，建議使用此選項。我們仍然建議完整地定期執行 DBCC CHECKDB。這些運行的執行頻率取決于各業務和生產環境特定的因素。

PHYSICAL_ONLY 始終表示 NO_INFOMSGS，不能與任何一個修復選項一同使用。

注意：

指定 PHYSICAL_ONLY 會使 DBCC CHECKDB 跳過對 FILESTREAM 數據的所有檢查。

DATA_PURITY
使 DBCC CHECKDB 檢查數據庫中是否存在無效或越界的列值。例如，DBCC CHECKDB 檢測日期和時間值大于或小于 datetime 數據類型的可接受范圍的列，或者小數位數或精度值無效的 decimal 或近似 numeric 數據類型列。

對于在 SQL Server 2005 及更高版本中創建的數據庫，默認情況下將啟用列值完整性檢查，并且不需要使用 DATA_PURITY 選項。對于從 SQL Server 的早期版本升級的數據庫，默認情況下不啟用列值檢查，直到 DBCC CHECKDB WITH DATA_PURITY 已在數據庫中正確運行為止。然后，DBCC CHECKDB 將默認檢查列值完整性。有關從 SQL Server 的早期版本升級數據庫會對 CHECKDB 有何影響的詳細信息，請參閱本主題的“備注”部分。

如果指定了 PHYSICAL_ONLY，則不執行列完整性檢查。

無法使用 DBCC 修復選項來糾正該選項所報告的驗證錯誤。

http://msdn.microsoft.com/zh-cn/library/ms176064.aspx

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈