DBCC CHECKDB (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
  這是要執行完整性檢查的資料庫識別碼或名稱。 若未指定，或指定 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
  根據每個物件顯示所有報告的錯誤。 系統預設會顯示所有錯誤訊息。 指定或省略這個選項沒有任何作用。 錯誤訊息是依物件識別碼排序，但從 tempdb 資料庫產生的訊息除外。

  在 SQL Server Management Studio 中，傳回的最大錯誤訊息數目是 1000。 使用 Management Studio 時，您可能需要在指定 ALL_ERRORMSGS 時多次執行 DBCC CHECKDB，才能取得完整的錯誤清單。 指定 ALL_ERRORMSGS 時，建議您使用 sqlcmd 公用程式來執行 DBCC 命令，或是排程 SQL Server Agent 作業來執行該命令，並將輸出導向檔案。 執行任何其中一種方式，都可確保執行一次命令將能回報所有錯誤訊息。

• 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
  將檢查限制於頁面實體結構、記錄標頭的完整性，以及資料庫配置的一致性。 這是設計來對資料庫實體一致性提供少量負擔檢查，這項檢查還能偵測到可能危及使用者資料的損毀頁、總和檢查碼失敗以及常見的硬體錯誤。

  完整執行 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 或近似數值資料類型資料行具有無效的小數位數或有效位數值。

  對於在 SQL Server 2005 及更新版本中建立的資料庫而言，預設會啟用資料行值的完整性檢查，而不需要 DATA_PURITY 選項。 對於從舊版 SQL Server 升級的資料庫，在毫無錯誤的情況下完成對資料庫執行 DBCC CHECKDB WITH DATA_PURITY 之前，依預設不啟用資料行值的完整性檢查。 此後，依預設 DBCC CHECKDB 會檢查資料行值的完整性。 如需有關從舊版 SQL Server 升級資料庫可能對 CHECKDB 造成何種影響的詳細資訊，請參閱本主題稍後的「備註」一節。

  如果指定 PHYSICAL_ONLY，則不會執行資料行完整性檢查。

  這個選項報告的驗證錯誤無法使用 DBCC 修復選項更正。 如需有關手動這些更正錯誤的詳細資訊，請參閱知識庫文件 923247：＜疑難排解 SQL Server 2005 中的 DBCC 錯誤 2570＞(英文)。

備註

在舊版 SQL Server 中，各資料表和各索引資料列數和頁數值可能會變得不正確。 在某些情況下，這些值當中有一個或多個甚至可能變成負數。 在 SQL Server 2005 和更新版本中，永遠會正確維護這些值。 因此，在 SQL Server 2005 及更新版本上建立的資料庫絕不可包含錯誤的計數；不過，升級為 SQL Server 2005 及更新版本的資料庫則可以。 這並不代表資料庫中儲存的任何資料已經損毀。 DBCC CHECKDB 已經增強為可以偵測到這些計數中有任何一個變成負數的情況。 在偵測到負數計數時，DBCC CHECKDB 輸出將包含警告，並建議您執行 DBCC UPDATEUSAGE 來更正這個問題。

DBCC CHECKDB 不會檢查停用的索引。 如需有關停用索引的詳細資訊，請參閱＜停用索引＞。

如果使用者定義型別標示為按位元組排序，該使用者定義型別只能有一個序列。 按位元組排序之使用者定義型別如果沒有一致的序列，DBCC CHECKDB 執行期間將會發生錯誤 2537。 如需詳細資訊，請參閱＜使用者定義型別需求＞。

因為 Resource 資料庫只能在單一使用者模式中進行修改，無法直接對其執行 DBCC CHECKDB 命令。 然而，針對 master 資料庫執行 DBCC CHECKDB 時，在內部也會對 Resource 資料庫執行第二個 CHECKDB。 這表示 DBCC CHECKDB 可能會傳回額外的結果。 這個命令在未設定選項或僅設定 PHYSICAL_ONLY 或 ESTIMATEONLY 選項其中之一時，會傳回額外的結果集。

在 SP2 之前的 SQL Server 2005 版本中，執行 DBCC CHECKDB 會清除 SQL Server 執行個體的計畫快取。 清除計畫快取會導致重新編譯所有後續執行計畫，而且可能會導致查詢效能突然暫時下降。 在 SP2 及更新版本中，執行 DBCC CHECKDB 不會清除計畫快取。

對索引執行邏輯一致性檢查

內部資料庫快照集

檢查及修復 FILESTREAM 資料

最佳作法

平行檢查物件

了解 DBCC 錯誤訊息

錯誤報告

解決錯誤

以資料庫緊急模式解決錯誤

在複寫的資料庫中搭配執行 DBCC CHECKDB 與 REPAIR_ALLOW_DATA_LOSS

結果集

DBCC CHECKDB 會傳回下列結果集。 這些值可能會不同，除非指定了 ESTIMATEONLY、PHYSICAL_ONLY 或 NO_INFOMSGS 選項：

DBCC results for 'model'.

Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.

Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.

Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.

Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.

There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.

There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.

There are 195 rows in 3 pages for object 'sysallocunits'.

There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.

There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.

There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.

There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.

There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

指定 NO_INFOMSGS 時，DBCC CHECKDB 會傳回下列結果集 (訊息)：

The command(s) completed successfully.

指定 PHYSICAL_ONLY 時，DBCC CHECKDB 會傳回下列結果集：

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

指定 ESTIMATEONLY 時，DBCC CHECKDB 會傳回下列結果集。

Estimated TEMPDB space needed for CHECKALLOC (KB)

-------------------------------------------------

13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)

--------------------------------------------------

57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

權限

需要 sysadmin 固定伺服器角色或 db_owner 固定資料庫角色中的成員資格。

範例

A. 同時檢查目前的資料庫與另一個資料庫

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2008R2 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2008R2, NOINDEX);
GO

B. 檢查目前資料庫，不顯示參考訊息

DBCC CHECKDB WITH NO_INFOMSGS;
GO

請參閱

參考

概念

變更記錄