DBCC CHECKDB (Transact-SQL)

  • 發行項

更新： 2008 年 11 月 17 日

藉由執行下列作業，檢查指定資料庫中所有物件的邏輯完整性和實體完整性：

  • 對資料庫執行 DBCC CHECKALLOC。
  • 對資料庫中每一資料表和檢視執行 DBCC CHECKTABLE。
  • 對資料庫執行 DBCC CHECKCATALOG。
  • 驗證資料庫中每一索引檢視的內容。
  • 驗證資料庫中的 Service Broker 資料。

這表示 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG 命令不需要與 DBCC CHECKDB 分開獨立執行。如需有關這些命令執行之檢查的詳細資訊，請參閱這些命令的描述。

主題連結圖示Transact-SQL 語法慣例

語法

DBCC CHECKDB 
[
    [ ( database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
        ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , 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
      同時執行次要、快速的修復動作 (例如，修復非叢集索引中的額外索引鍵)，以及耗時的修復 (例如，重建索引)。執行這類修復沒有資料遺失的危險。
    ms176064.note(zh-tw,SQL.90).gif重要事項：
    最好不要使用這些 REPAIR 選項。若要修復錯誤，我們建議您從備份中還原。修復作業並不考慮資料表或資料表之間的任何條件約束。如果指定的資料表涉及一或多項條件約束，建議您在修復作業之後，執行 DBCC CHECKCONSTRAINTS。如果您必須使用 REPAIR，請執行不含修復選項的 DBCC CHECKDB 來尋找要使用的修復層級。如果您使用 REPAIR_ALLOW_DATA_LOSS 層級，建議您在搭配這個選項執行 DBCC CHECKDB 之前，先備份資料庫。

  • ALL_ERRORMSGS
    根據每個物件顯示所有報告的錯誤。在 SQL Server 2005 Service Pack 3 (SP3) 中，預設會顯示所有錯誤訊息。指定或省略這個選項沒有任何作用。在舊版 SQL Server 中，如果未指定 ALL_ERRORMSGS，則只會顯示每個物件的前 200 個錯誤訊息。錯誤訊息是依物件識別碼排序，但從 tempdb 資料庫產生的訊息除外。

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

  • NO_INFOMSGS
    抑制所有參考訊息。

  • TABLOCK
    使 DBCC CHECKDB 取得鎖定，而不使用內部資料庫快照集。這包括資料庫上的短期獨佔 (X) 鎖定。TABLOCK 可讓 DBCC CHECKDB 在負載沉重的資料庫上執行得快一些，但 DBCC CHECKDB 執行時，資料庫可用的並行會降低。如需有關鎖定的詳細資訊，請參閱＜鎖定模式＞。

    TABLOCK 會限制執行的檢查；不會對資料庫執行 DBCC CHECKCATALOG，也不會驗證 Service Broker 資料。

  • ESTIMATEONLY
    顯示設定所有其他指定的選項來執行 DBCC CHECKDB 所需要的 tempdb 估計空間量。不會執行實際的資料庫檢查。
  • PHYSICAL_ONLY
    將檢查限制於頁面實體結構、記錄標頭、B 型樹狀目錄實體結構的完整性，以及資料庫配置的一致性。這是設計來對資料庫實體一致性提供少量負擔檢查，這項檢查還能偵測到可能危及使用者資料的損毀頁、總和檢查碼失敗以及常見的硬體錯誤。PHYSICAL_ONLY 一律隱含 NO_INFOMSGS，不允許使用任何修復選項。

  • 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＞(英文)。

結果集

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.

備註

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

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

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

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

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

內部資料庫快照集

DBCC CHECKDB 使用內部資料庫快照集來維護執行這些檢查時所需的交易一致性。這可以防止在執行這些命令時，發生封鎖和並行問題。如需詳細資訊，請參閱＜瞭解資料庫快照集內的疏鬆檔案大小＞和＜DBCC (Transact-SQL)＞中的「DBCC 內部資料庫快照集使用方式」一節。如果無法建立快照集，或指定了 TABLOCK，則 DBCC CHECKDB 會獲取鎖定來取得必要的一致性。在這個情況下，則需要獨佔資料庫鎖定，才能執行配置檢查，需要共用資料表鎖定，才能執行資料表檢查。

如果無法建立內部資料庫快照集，在針對 master 執行 DBCC CHECKDB 時會失敗。

針對 tempdb 執行 DBCC CHECKDB 並不會執行任何配置或目錄檢查，且需要共用資料表鎖定來執行資料表檢查。這是因為基於效能的考量，tempdb 並無法使用資料庫快照集。這表示無法取得必要的交易一致性。

最佳作法

在 SQL Server 2005 中，不搭配任何選項執行 DBCC CHECKDB 所需要的時間可能比舊版長許多。下列是導致這種行為的可能原因：

  • 導入的邏輯檢查更完整。
  • 部分要檢查的基礎結構更複雜。
  • 導入了許多新的檢查，以併入 SQL Server 2005 中的新功能。

因此，建議您在實際執行系統上，使用 PHYSICAL_ONLY 選項做為常用的選項。使用 PHYSICAL_ONLY 可以大幅縮減在大型資料庫上執行 DBCC CHECKDB 所需的時間。我們也建議您不搭配使用任何選項，定期執行 DBCC CHECKDB。執行這些作業的頻率是依個別公司及其實際執行環境而定。

平行檢查物件

依預設，DBCC CHECKDB 會執行物件的平行檢查。查詢處理器會自動判斷平行處理原則的程度。最大平行處理原則程度的設定方式與平行查詢相同。若要限制 DBCC 檢查所能使用的最大處理器數目，請使用 sp_configure。如需詳細資訊，請參閱＜max degree of parallelism 選項＞。您可以利用追蹤旗標 2528 來停用平行檢查。如需詳細資訊，請參閱＜追蹤旗標 (Transact-SQL)＞。

了解 DBCC 錯誤訊息

DBCC CHECKDB 命令執行完成之後，SQL Server 錯誤記錄檔中會寫入一則訊息。如果 DBCC 命令執行成功，該訊息將指出命令已順利完成，並顯示命令執行的時間量。如果 DBCC 命令由於發生錯誤而在完成檢查之前停止執行，則訊息會指出命令已經結束，並顯示狀態值以及命令執行的時間量。下表列出並描述可以包含在訊息中的狀態值。

狀態 描述

0

已引發錯誤號碼 8930。這表示中繼資料中的損毀導致 DBCC 命令結束。

1

已引發錯誤號碼 8967。發生內部 DBCC 錯誤。

2

修復緊急模式資料庫期間發生失敗。

3

這表示中繼資料中的損毀導致 DBCC 命令結束。

4

偵測到判斷提示或存取違規。

5

發生使 DBCC 命令終止的未知錯誤。

錯誤報告

在 SQL Server 2005 Service Pack 1 中，每當 DBCC CHECKDB 偵測到損毀錯誤時，都會在 SQL Server LOG 目錄中建立傾印檔案 (SQLDUMPnnnn.txt)。當 SQL Server 的執行個體已啟用「功能使用方式」資料收集及「錯誤報告」功能時，這個檔案會自動轉送到 Microsoft。收集的資料是用來提升 SQL Server 的功能。如需詳細資訊，請參閱＜錯誤和使用方式報表設定＞。

傾印檔案包含 DBCC CHECKDB 命令的結果以及其他診斷輸出。存取權限制為 SQL Server 服務帳戶及 sysadmin 角色的成員。根據預設，sysadmin 角色包含 Windows BUILTIN\Administrators 群組以及本機管理員群組的所有成員。如果資料收集程序失敗，DBCC 命令不會失敗。

解決錯誤

如果 DBCC CHECKDB 報告任何錯誤，建議您從資料庫備份還原資料庫，而不要設定下列 REPAIR 選項之一來執行 REPAIR。如果沒有任何備份，執行修復可以更正所報告的錯誤。要用的 REPAIR 選項指定在報告的錯誤清單尾端。不過，利用 REPAIR_ALLOW_DATA_LOSS 選項來更正錯誤，可能需要刪除某些頁面，因而也需要刪除某些資料。

在某些情況下，可能會將對資料行的資料類型無效或超出範圍的值輸入資料庫中。在 SQL Server 2000 中，DBCC CHECKDB 不會對這些資料行值執行範圍或完整性檢查。然而在 SQL Server 2005 中，DBCC CHECKDB 可以偵側到對所有資料行資料類型無效的資料行值。因此，配合 DATA_PURITY 選項對從舊版 SQL Server 升級的資料庫執行 DBCC CHECKDB，可以發現預先存在的資料行值錯誤。因為 SQL Server 2005 無法自動修復這些錯誤，資料行值必須手動更新。如果 CHECKDB 偵測到這類錯誤，CHECKDB 會傳回警告，錯誤碼 2570，以及識別受影響資料列和手動更正錯誤的資訊。

修復動作可在某項使用者交易之下執行，讓使用者可以回復所做的變更。如果回復修復，資料庫仍會包含錯誤，且必須從備份中還原。修復動作完成之後，請備份資料庫。

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

如果已經利用 ALTER DATABASE 陳述式將資料庫設為緊急模式，則 DBCC CHECKDB 可以在資料庫上執行某些特殊的修復作業 (如果已指定 REPAIR_ALLOW_DATA_LOSS 選項)。這些修復可讓一般無法修復的資料庫以實體一致的狀態重新上線。只有在資料庫無法從備份還原時，才應該使用上述修復來當做最後手段。當資料庫設為緊急模式時，資料庫會標示為 READ_ONLY、停用記錄並限定只有 sysadmin 固定伺服器角色的成員才可存取。

ms176064.note(zh-tw,SQL.90).gif附註：
使用緊急模式時，無法在使用者交易內執行 DBCC CHECKDB 命令並在執行後回復交易。

當資料庫處於緊急模式且執行了 DBCC CHECKDB (具有 REPAIR_ALLOW_DATA_LOSS 子句) 時，將會採取下列動作：

  • DBCC CHECKDB 會使用因 I/O 或總和檢查碼錯誤而標示為無法存取的頁面，如同未發生錯誤一樣。執行這個動作，可增加從資料庫復原資料的機會。
  • DBCC CHECKDB 會試圖利用正規記錄式復原技術來復原資料庫。
  • 如果資料庫復原因交易記錄損毀而無法成功，就會重建交易記錄。重建交易記錄可能會導致無法維持交易一致性。

如果 DBCC CHECKDB 命令成功完成，則資料庫會處於實體一致的狀態，且資料庫狀態會設為 ONLINE。不過，資料庫可能會包含一個或多個交易不一致的狀況。建議您執行 DBCC CHECKCONSTRAINTS 以識別是否有任何商務邏輯的缺陷，並且立即備份資料庫。

如果 DBCC CHECKDB 命令失敗，資料庫就無法修復。

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

搭配執行 DBCC CHECKDB 命令與 REPAIR_ALLOW_DATA_LOSS 選項時，可能會影響使用者資料庫 (發行集和訂閱資料庫) 以及複寫所使用的散發資料庫。發行集和訂閱資料庫包含已發行資料表和複寫中繼資料表。請注意這些資料庫中的下列潛在問題：

  • 已發行資料表。由 CHECKDB 處理序執行以修復損毀使用者資料的動作可能並未複寫：
    • 合併式複寫使用觸發程序來追蹤已發行資料表的變更。如果資料列是由 CHECKDB 處理序插入、更新或刪除，將不會引發觸發程序；因此，也不會複寫變更。
    • 交易式複寫使用交易記錄來追蹤已發行資料表的變更。記錄讀取器代理程式接著會將這些變更移到散發資料庫。某些 DBCC 修復雖然已經記錄，但卻不能由記錄讀取器代理程式加以複寫。例如，如果資料頁已由 CHECKDB 處理序取消配置，記錄讀取器代理程式就不會將它轉譯成 DELETE 陳述式；因此，也不會複寫變更。
  • 複寫中繼資料表。由 CHECKDB 處理序執行以修復損毀複寫中繼資料表的動作需要移除及重新設定複寫。

如果您必須在使用者資料庫或散發資料庫上搭配執行 DBCC CHECKDB 命令與 REPAIR_ALLOW_DATA_LOSS 選項：

  1. 停止系統：停止該資料庫以及複寫拓撲中其他所有資料庫的活動，然後嘗試同步處理所有節點。如需詳細資訊，請參閱＜How to: Quiesce a Replication Topology (Replication Transact-SQL Programming)＞。
  2. 執行 DBCC CHECKDB。
  3. 如果 DBCC CHECKDB 報表包含散發資料庫中任何資料表的修復，或包含使用者資料庫中任何複寫中繼資料表的修復，請移除並重新設定複寫。如需詳細資訊，請參閱＜移除複寫＞。
  4. 如果 DBCC CHECKDB 報表包含任何已複寫資料表的修復，請執行資料驗證以判斷發行集與訂閱資料庫之間的資料是否有差異。如需詳細資訊，請參閱＜發行者端與訂閱者端的資料不符＞。

權限

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

範例

A. 同時檢查目前及 AdventureWorks 資料庫

下列範例會針對目前資料庫和 AdventureWorks 資料庫執行 DBCC CHECKDB。

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

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

下列範例會檢查目前資料庫，且抑制所有參考訊息。

DBCC CHECKDB WITH NO_INFOMSGS;
GO

請參閱

參考

DBCC (Transact-SQL)
sp_helpdb (Transact-SQL)
系統資料表 (Transact-SQL)

其他資源

實體資料庫架構
瞭解資料庫快照集內的疏鬆檔案大小
疑難排解索引檢視的 DBCC 錯誤
最佳化 DBCC CHECKDB 效能

說明及資訊

取得 SQL Server 2005 協助

變更歷程記錄

版本 歷程記錄

2008 年 11 月 17 日
新增內容：
  • 在 ALL_ERRORMSGS 的定義中，描述 SP3 的新增功能。

2006 年 12 月 12 日
新增內容：
  • 在「備註」中新增 DBCC CHECKDB 何時會清除計劃快取的資訊。

2006 年 7 月 17 日
新增內容：
  • 新增有關如何使用 ALL_ERRORMSGS 的定義傳回所有錯誤訊息的資訊。

2006 年 4 月 14 日
新增內容：
  • 新增「錯誤報告」一節。此章節會描述 SP1 中的新功能。
  • 新增「以資料庫緊急模式解決錯誤」一節。

2005 年 12 月 5 日
新增內容：
  • 新增有關按位元組排序之使用者定義類別的錯誤訊息 2537 的資訊。
  • 新增「在複寫的資料庫中搭配執行 DBCC CHECKDB 與 REPAIR_ALLOW_DATA_LOSS」一節。
  • 新增「了解 DBCC 錯誤訊息」一節。
變更的內容：
  • 更正語法。
  • 更正 REPAIR_FAST 定義。此選項不會執行修復動作。
  • 加入指定選項時不會執行的作業，以更正 TABLOCK 定義。