DBCC 數(shù)據(jù)庫錯誤檢查與修復

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

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 } ] } ]
]

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

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

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
指定 DBCC CHECKDB 修復發(fā)現(xiàn)的錯誤。指定的數(shù)據(jù)庫必須處于單用戶模式，才能使用以下修復選項之一。

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

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

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

REPAIR_REBUILD 不修復涉及 FILESTREAM 數(shù)據(jù)的錯誤。

重要提示：

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

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

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

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

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

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

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

TABLOCK 限制執(zhí)行的檢查；DBCC CHECKCATALOG 未對數(shù)據(jù)庫運行并且 Service Broker 數(shù)據(jù)未進行驗證。

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

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

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

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

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

注意：

指定 PHYSICAL_ONLY 會使 DBCC CHECKDB 跳過對 FILESTREAM 數(shù)據(jù)的所有檢查。

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

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

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

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

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

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