DBCC CHECKDB (Transact-SQL)

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

• 對資料庫執行 DBCC CHECKALLOC。

• 對資料庫中每一資料表和檢視執行 DBCC CHECKTABLE。

• 對資料庫執行 DBCC CHECKCATALOG。

• 驗證資料庫中每一索引檢視的內容。

• 當使用 FILESTREAM 將 varbinary(max) 資料儲存在檔案系統中時，驗證資料表中繼資料與檔案系統目錄和檔案之間的連結層級一致性。

• 驗證資料庫中的 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 ]
            [ , 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
  根據每個物件顯示所有報告的錯誤。在 SQL Server 2008 Service Pack 1 (SP1) 中，預設會顯示所有錯誤訊息。指定或省略這個選項沒有任何作用。在舊版 SQL Server 中 (除了 SQL Server 2005 SP3)，如果未指定 ALL_ERRORMSGS，則只會顯示每個物件的前 200 個錯誤訊息。錯誤訊息是依物件識別碼排序，但從 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 不會清除計畫快取。

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

對索引進行的邏輯一致性檢查會根據資料庫的相容性層級而異，如下所示：

• 如果相容性層級為 100 (SQL Server 2008) 或更高：

  • 除非指定了 NOINDEX，否則 DBCC CHECKDB 會針對單一資料表及它的所有非叢集索引進行實體和邏輯一致性檢查。但是根據預設，XML 索引、空間索引和索引檢視表只會進行實體一致性檢查。

  • 如果指定了 WITH EXTENDED_LOGICAL_CHECKS，將會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯檢查。根據預設，實體一致性檢查會在邏輯一致性檢查之前執行。如果也指定了 NOINDEX，則只會執行邏輯檢查。

    這些邏輯一致性檢查會交叉檢查索引物件的內部索引資料表 (其中包含它所參考的使用者資料表)。若要尋找外圍的資料列，則會建構內部查詢來執行內部和使用者資料表的完整交集。執行這個查詢對於效能會有極大的影響，而且無法追蹤其進度。因此，只有當您懷疑發生了與實體損毀無關的索引問題，或是頁面層級總和檢查碼已經關閉，而且您懷疑發生了資料行層級的硬體損毀時，才建議您指定 WITH EXTENDED_LOGICAL_CHECKS。

  • 如果此索引為已篩選的索引，DBCC CHECKDB 會執行一致性檢查，以確認索引項目可滿足篩選述詞。

• 如果相容性層級為 90 以下，則除非指定了 NOINDEX，否則 DBCC CHECKDB 會針對單一資料表或索引檢視表及它的所有非叢集索引和 XML 索引進行實體和邏輯一致性檢查。不支援空間索引。

了解資料庫的相容性層級

• 如何：檢視或變更資料庫的相容性層級 (SQL Server Management Studio)

內部資料庫快照集

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

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

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

檢查及修復 FILESTREAM 資料

當資料庫和資料表啟用了 FILESTREAM 時，您可以選擇將 varbinary(max) 二進位大型物件 (BLOB) 儲存在檔案系統中。當您針對將 BLOB 儲存於檔案系統中的資料庫使用 DBCC CHECKDB 時，DBCC 會檢查檔案系統與資料庫之間的連結層級一致性。

例如，如果資料表包含了使用 FILESTREAM 屬性的 varbinary(max) 資料行，DBCC CHECKDB 將會檢查檔案系統目錄和檔案與資料表資料列、資料行和資料行值之間是否有一對一的對應。如果您指定 REPAIR_ALLOW_DATA_LOSS 選項，則 DBCC CHECKDB 可以修復損毀。若要修復 FILESTREAM 損毀，DBCC 將會刪除遺失檔案系統資料的任何資料表資料列，而且將會刪除未對應到資料表資料列、資料行或資料行值的任何檔案和目錄。

最佳作法

我們建議您在實際執行系統上，使用 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 命令終止的未知錯誤。

錯誤報告

每當 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 無法自動修復這些錯誤，所以資料行值必須手動更新。如果 CHECKDB 偵測到這類錯誤，CHECKDB 會傳回警告，錯誤碼 2570，以及識別受影響資料列和手動更正錯誤的資訊。

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

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

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

[!附註]

使用緊急模式時，無法在使用者交易內執行 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. 停止系統：停止該資料庫以及複寫拓撲中其他所有資料庫的活動，然後嘗試同步處理所有節點。如需詳細資訊，請參閱＜如何：停止複寫拓撲 (複寫 Transact-SQL 程式設計)＞。

2. 執行 DBCC CHECKDB。

3. 如果 DBCC CHECKDB 報表包含散發資料庫中任何資料表的修復，或包含使用者資料庫中任何複寫中繼資料表的修復，請移除並重新設定複寫。如需詳細資訊，請參閱＜移除複寫＞。

4. 如果 DBCC CHECKDB 報表包含任何已複寫資料表的修復，請執行資料驗證以判斷發行集與訂閱資料庫之間的資料是否有差異。如需詳細資訊，請參閱＜發行者端與訂閱者端的資料不符＞。

結果集

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

DBCC 對 'model' 的結果。

Service Broker 訊息 9675，層級 10，狀態 1: 已分析訊息類型: 13。

Service Broker 訊息 9676，層級 10，狀態 1: 已分析服務合約: 5。

Service Broker 訊息 9667，層級 10，狀態 1: 已分析服務: 3。

Service Broker 訊息 9668，層級 10，狀態 1: 已分析服務佇列: 3。

Service Broker 訊息 9669，層級 10，狀態 1: 已分析交談端點: 0。

Service Broker 訊息 9674，層級 10，狀態 1: 已分析交談群組: 0。

Service Broker 訊息 9670，層級 10，狀態 1: 已分析遠端服務繫結: 0。

DBCC 對 'sys.sysrowsetcolumns' 的結果。

物件 'sys.sysrowsetcolumns' 在 7 頁面中有 630 個資料列。

DBCC 對 'sys.sysrowsets' 的結果。

物件 'sys.sysrowsets' 在 1 頁面中有 97 個資料列。

DBCC 對 'sysallocunits' 的結果。

物件 'sysallocunits' 在 3 頁面中有 195 個資料列。

物件 "sys.sysasymkeys" 在 0 頁面中有 0 個資料列。

DBCC 對 'sys.syssqlguides' 的結果。

物件 "sys.syssqlguides" 在 0 頁面中有 0 個資料列。

DBCC 對 'sys.queue_messages_1977058079' 的結果。

物件 "sys.queue_messages_1977058079" 在 0 頁面中有 0 個資料列。

DBCC 對 'sys.queue_messages_2009058193' 的結果。

物件 "sys.queue_messages_2009058193" 在 0 頁面中有 0 個資料列。

DBCC 對 'sys.queue_messages_2041058307' 的結果。

物件 "sys.queue_messages_2041058307" 在 0 頁面中有 0 個資料列。

CHECKDB 發現了資料庫 'model' 中 0 個配置錯誤和 0 個一致性錯誤。

DBCC 的執行已經完成。如果 DBCC 印出錯誤訊息，請連絡您的系統管理員。

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

命令已順利完成。

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

DBCC 對 'model' 的結果。

CHECKDB 發現了資料庫 'master' 中 0 個配置錯誤和 0 個一致性錯誤。

DBCC 的執行已經完成。如果 DBCC 印出錯誤訊息，請連絡您的系統管理員。

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

估計 CHECKALLOC 所需的 TEMPDB 空間 (KB)

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

13

(1 個資料列受到影響)

估計 CHECKTABLES 所需的 TEMPDB 空間 (KB)

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

57

(1 個資料列受到影響)

DBCC 的執行已經完成。如果 DBCC 印出錯誤訊息，請連絡您的系統管理員。

權限

需要 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

變更記錄

更新的內容
在 PHYSICAL_ONLY 的定義中，在指定此子句時所檢查的項目清單中已移除「B 型樹狀目錄之實體結構」。
在 ALL_ERRORMSGS 的定義中，描述 SQL Server 2008 SP1 的新增功能。

請參閱

參考

DBCC (Transact-SQL)

sp_helpdb (Transact-SQL)

系統資料表 (Transact-SQL)

概念

了解資料庫快照集內的疏鬆檔案大小

疑難排解索引檢視的 DBCC 錯誤

最佳化 DBCC CHECKDB 效能