DBCC CHECKDB (Transact-SQL)

發行項
12/21/2024

適用於：SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體

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

對資料庫執行 DBCC CHECKALLOC。
對資料庫中每一資料表和檢視執行 DBCC CHECKTABLE。
對資料庫執行 DBCC CHECKCATALOG。
驗證資料庫中每一索引檢視的內容。
當使用 FILESTREAM 將 varbinary(max) 資料儲存在檔案系統中時，驗證資料表中繼資料與檔案系統目錄和檔案之間的連結層級一致性。
驗證資料庫中的 Service Broker 資料。

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

在包含記憶體最佳化資料表的資料庫中，可支援 DBCC CHECKDB，但是只會在磁碟資料表上進行驗證。不過，在資料庫備份和復原中，會針對記憶體優化檔案群組中的檔案執行 CHECKSUM 驗證。

因為 DBCC 修復選項無法用於記憶體最佳化資料表，所以您必須定期備份資料庫，並測試備份。如果記憶體最佳化資料表中發生資料完整性問題，您必須從最後已知的良好備份還原。

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 } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

引數

database_name | database_id | 0

要執行完整性檢查的資料庫識別碼或名稱。若未指定，或指定 0，就會使用目前的資料庫。資料庫名稱必須符合識別碼的規則。

NOINDEX

指定不會針對用戶數據表執行非叢集索引的密集檢查。這個選項會減少整體的執行時間。 NOINDEX 不會影響系統資料表，因為系統資料表索引一律會執行完整性檢查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定 DBCC CHECKDB 修復找到的錯誤。僅使用 REPAIR_* 選項作為最後手段。指定的資料庫必須為單一使用者模式，才能使用下列修復選項之一。

REPAIR_ALLOW_DATA_LOSS

嘗試修復所有報告的錯誤。這些修復可能會造成某些資料的遺失。

警告

REPAIR_ALLOW_DATA_LOSS 選項可能會導致比從最近的良好備份還原更多的數據喪失。請參閱REPAIR_ALLOW_DATA_LOSS 數據遺失警告

Microsoft 一律建議使用者從上次已知良好的備份還原，作為修復 DBCC CHECKDB 所報告錯誤的主要方法。 REPAIR_ALLOW_DATA_LOSS 選項無法取代從已知良好的備份還原方法。這是緊急 最後手段 選項建議只有在無法從備份還原時才使用。

某些只能使用 [REPAIR_ALLOW_DATA_LOSS] 選項修復的錯誤，可能涉及解除配置數據列、頁面或一系列頁面來清除錯誤。用戶無法再存取或復原任何已解除分配的數據，也無法判斷已解除分配數據的確切內容。因此，在取消配置任何數據列或頁面之後，引用完整性可能不正確，因為不會檢查或維護外鍵條件約束，作為此修復作業的一部分。使用者在使用 DBCC CHECKCONSTRAINTS 選項之後，必須檢查其資料庫的參考完整性 (使用 REPAIR_ALLOW_DATA_LOSS)。

在執行修復之前，您必須建立屬於這個資料庫的檔案實體複本。這包括主要資料檔 (.mdf)、任何次要資料檔 (.ndf)、所有交易記錄檔 (.ldf) 以及其他構成資料庫的容器，包括全文檢索目錄、檔案資料流資料夾、記憶體最佳化的資料等。

在執行修復之前，請考慮將資料庫的狀態變更為 EMERGENCY 模式，並嘗試從關鍵資料表中擷取盡可能最多的資訊，然後儲存該資料。
REPAIR_FAST

維護這個語法的目的，只是為了與舊版相容。不會執行任何修復動作。
REPAIR_REBUILD

執行不可能造成資料遺失的修復，此選項可能包含快速修復，例如修復非叢集索引中的遺漏數據列，以及更耗時的修復，例如重建索引。

此引數不會修復涉及 FILESTREAM 資料的錯誤。

重要

由於 DBCC CHECKDB 與任何 REPAIR_* 選項的操作都已完整記錄且可復原，因此 Microsoft 一向建議使用者在交易中使用 DBCC CHECKDB 搭配任何 REPAIR_* 選項（於執行命令前先執行 BEGIN TRANSACTION），以便使用者能確認是否接受作業結果。接著使用者可執行 COMMIT TRANSACTION，來認可修復作業完成的所有工作。如果使用者不想接受作業的結果，他們可以執行 ROLLBACK TRANSACTION 來復原修復作業的效果。

若要修復錯誤，我們建議您從備份中還原。修復作業不會考慮數據表上或數據表之間可能存在的任何限制條件。如果指定的資料表涉及一或多項條件約束，建議您在修復作業之後執行 DBCC CHECKCONSTRAINTS。如果您必須使用 REPAIR_*，請在不選擇修復選項的情況下執行 DBCC CHECKDB，以確定要使用的修復層級。如果您使用 REPAIR_ALLOW_DATA_LOSS 層級，建議您在搭配此選項執行 DBCC CHECKDB 之前，先備份資料庫。

ALL_ERRORMSGS

根據每個物件顯示所有報告的錯誤。系統預設會顯示所有錯誤訊息。指定或省略這個選項沒有任何作用。錯誤訊息是依物件識別碼排序，但從 tempdb 資料庫產生的訊息除外。

EXTENDED_LOGICAL_CHECKS

如果相容性層級為 100 (在 SQL Server 2008 (10.0.x) 中引入)，則此選項會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯一致性檢查。

如需詳細資訊，請參閱本文稍後的對索引執行邏輯一致性檢查。

NO_INFOMSGS

隱藏所有參考訊息。

TABLOCK

使 DBCC CHECKDB 取得鎖定，而不使用內部資料庫快照集。這包括資料庫上的短期獨佔 (X) 鎖定。 TABLOCK 會導致 DBCC CHECKDB 在負載過重的資料庫上執行得更快，但在執行 DBCC CHECKDB 時，會減少資料庫可用的並行。

重要

TABLOCK 限制執行的檢查;DBCC CHECKCATALOG 未在資料庫上執行，而且不會驗證 Service Broker 數據。

ESTIMATEONLY

顯示利用其他所有指定的選項來執行 tempdb 所需要的 DBCC CHECKDB 估計空間量。不會執行實際的資料庫檢查。

PHYSICAL_ONLY

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

完整執行 DBCC CHECKDB 可能需要比舊版更長的時間才能完成。此行為的發生狀況如下：

邏輯檢查更完整。
部分要檢查的基礎結構更複雜。
導入了許多新的檢查，以包含新的功能。

因此，使用 PHYSICAL_ONLY 選項可能會導致大型資料庫的 DBCC CHECKDB 運行時間較短，因此建議在生產系統上經常使用。我們仍建議您定期完整執行 DBCC CHECKDB。這些執行動作的頻率取決於個別商務和實際執行環境特有的因素。

此引數一律隱含 NO_INFOMSGS，且不允許搭配任何修復選項使用。

警告

指定 PHYSICAL_ONLY 會導致 DBCC CHECKDB 略過所有 FILESTREAM 資料的檢查。

DATA_PURITY

使 DBCC CHECKDB 檢查資料庫，找出無效或超出範圍的資料行值。例如，DBCC CHECKDB 會偵測具有大於或小於 datetime 資料類型可接受範圍日期和時間值的資料行；或是小數位數或有效位數值無效的 decimal 或近似數值資料類型資料行。

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

警告

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

這個選項報告的驗證錯誤無法使用 DBCC 修復選項修正。如需手動更正這些錯誤的相關信息，請參閱 MSSQLSERVER_2570。

MAXDOP

適用於：SQL Server 2014 (12.x) Service Pack 2 和更新版本

覆寫語句中 sp_configure 的 max degree of parallelism 組態選項。 MAXDOP 可能會超過使用 sp_configure 所設定的值。如果 MAXDOP 超過使用 Resource Governor 所設定的值，SQL Server 資料庫引擎就會使用 MAXDOP 中所描述的 Resource Governor 值。當您使用 MAXDOP 查詢提示時，所有搭配 max degree of parallelism 組態選項使用的語意規則都適用。如需詳細資訊，請參閱伺服器組態：平行處理原則的最大程度。

警告

如果 MAXDOP 設定為零，SQL Server 會選擇要使用的 max degree of parallelism。

備註

DBCC CHECKDB 不會檢查停用的索引。如需有關停用索引的更多資訊，請參閱停用索引和約束條件。

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

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

在 SQL Server 2005 （9.x） Service Pack 2 和更新版本中，執行 DBCC CHECKDB 不再清除 SQL Server 實例的計劃快取。在 SQL Server 2005 (9.x) Service Pack 2 之前，執行 DBCC CHECKDB 會清除計畫快取。清除計劃快取會導致重新編譯所有後續的執行計劃，而且可能會導致查詢效能突然暫時減少。

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

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

如果相容性層級至少是 100 (在 SQL Server 2008 (10.0.x) 中引進)：
除非指定了 NOINDEX，否則 DBCC CHECKDB 會針對單一資料表及其所有非叢集索引進行實體和邏輯一致性檢查。但是根據預設，XML 索引、空間索引和索引檢視表只會進行實體一致性檢查。
如果指定了 WITH EXTENDED_LOGICAL_CHECKS，將會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯檢查。根據預設，實體一致性檢查會在邏輯一致性檢查之前執行。如果也指定了 NOINDEX，則只會執行邏輯檢查。

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

如果此索引為已篩選的索引，則 DBCC CHECKDB 會執行一致性檢查，以確認索引項目可滿足篩選述詞。
如果相容性層級為 90 以下，則除非指定了 NOINDEX，否則 DBCC CHECKDB 會針對單一資料表或索引檢視表及其所有非叢集索引和 XML 索引進行實體和邏輯一致性檢查。不支援空間索引。
在 SQL Server 2016 （13.x）和更新版本中，為了避免耗費成本高的表達式評估，預設不會執行持續計算欄位、UDT 欄位和篩選索引的額外檢查。這項變更可大幅減少對包含這些物件的資料庫執行 CHECKDB 的持續時間。不過，系統一律會完成這些物件的實體一致性檢查。只有在指定 EXTENDED_LOGICAL_CHECKS 選項時，才會執行運算式評估，以及執行 EXTENDED_LOGICAL_CHECKS 選項中已存在的邏輯檢查 (索引檢視表、XML 索引及空間索引)。

了解資料庫的相容性層級

檢視或變更資料庫的相容性層級

內部資料庫快照集

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

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

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

從 SQL Server 2014 開始，DBCC CHECKDB 如何建立內部快照集資料庫

DBCC CHECKDB 會建立內部快照集資料庫。
內部快照集資料庫是使用實體檔案所建立。例如，對於標識為 database_id = 10 的資料庫，其包含三個檔案 E:\Data\my_DB.mdf、E:\Data\my_DB.ndf和 E:\Data\my_DB.ldf，內部快照集資料庫會使用 E:\Data\my_DB.mdf_MSSQL_DBCC11 和 E:\Data\my_DB.ndf_MSSQL_DBCC11 檔案建立。快照集的 database_id 是 database_id + 1。另請注意，系統會使用命名慣例 <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>，在相同的資料夾中建立新檔案。不會為交易記錄建立疏鬆檔案。
新檔案會在檔案系統層級標示為疏鬆檔案。新檔案所使用的磁碟大小會根據命令期間源資料庫中更新的數據量而增加。新檔案大小與 .mdf 或 .ndf 檔案相同。
新檔案會在 DBCC CHECKDB 處理結束時刪除。這些由 DBCC CHECKDB 建立的疏鬆檔案已設定「關閉時刪除」屬性。

警告

如果操作系統在 DBCC CHECKDB 命令進行時遇到非預期的關機，則不會清除這些檔案。它們佔用空間，可能會導致未來 DBCC CHECKDB 的執行失敗。在此情況下，您可以在確認目前未執行 DBCC CHECKDB 命令之後刪除這些新檔案。

使用 Windows 檔案總管之類的一般檔案公用程式，可看見新的檔案。

注意

在 SQL Server 2014 (12.x) 之前，會改用具名檔案串流來建立內部快照集檔案。具名檔案數據流使用 filename.extension<：MSSQL_DBCC>database_id_of_snapshot<格式>。使用 Windows 檔案總管等一般檔案公用程式，無法看到具名檔案流。因此，在 SQL Server 2012 （11.x）和舊版中，當您針對位於 ReFS格式磁碟區的資料庫檔案執行 DBCC CHECKDB 命令時，可能會遇到錯誤訊息 7926 和 5030。這是因為無法在彈性檔案系統 (ReFS)上建立檔案資料流。

檢查並修復 FILESTREAM 資料

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

例如，如果數據表包含 varbinary（max） 使用 FILESTREAM 屬性的數據行，DBCC CHECKDB 會檢查文件系統目錄與檔案和數據表數據列、數據行和數據行值之間是否有一對一對應。如果您指定 DBCC CHECKDB 選項，則 REPAIR_ALLOW_DATA_LOSS 可以修復損毀。若要修復 FILESTREAM 損毀，DBCC 會刪除遺漏文件系統數據的任何數據表數據列。

最佳做法

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

Azure SQL 受控執行個體，不論數據實際使用多少，可用的儲存空間都必須容納所DBCC CHECKDB建立的整個內部資料庫快照集檔案。這可能會導致在非常大型但疏鬆的資料庫上執行 DBCC CHECKDB 的情況（數據大小比資料庫檔案大小小得多），因為 SQL 受控實例上缺少空間而失敗。如果在 DBCC CHECKDB 執行期間取用所有可用的儲存空間，您會收到下列錯誤訊息：

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

平行檢查物件

根據預設，DBCC CHECKDB 會執行物件的平行檢查。查詢處理器會自動判斷平行處理原則的程度。最大平行處理原則程度的設定方式與平行查詢相同。若要限制 DBCC 檢查所能使用的最大處理器數目，請使用 sp_configure。如需詳細資訊，請參閱伺服器組態：平行處理原則的最大程度。您可以使用追蹤旗標 2528 來停用平行檢查。如需詳細資訊，請參閱追蹤旗標。

注意

此功能不適用於每個 SQL Server 版本。如需詳細資訊，請參閱 SQL Server 2022 的版本和支援的功能中 RDBMS 管理能力一節的平行一致性檢查。

了解 DBCC 錯誤訊息

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

State	描述
`0`	已引發錯誤號碼 8930。這表示中繼資料中的損毀導致 DBCC 命令結束。
`1`	已引發錯誤號碼 8967。發生內部 DBCC 錯誤。
`2`	修復緊急模式資料庫期間發生失敗。
`3`	這表示中繼資料中的損毀導致 DBCC 命令結束。
`4`	偵測到判斷提示或存取違規。
`5`	發生使 DBCC 命令終止的未知錯誤。

SQL Server 會記錄資料庫執行一致性檢查且沒有錯誤的日期和時間 (或「乾淨的」一致性檢查)。這稱為 last known clean check。在第一次啟動資料庫時，此日期會以下列格式寫入至 EventLog (EventID-17573) 和錯誤記錄檔：

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

錯誤報告

每當 DBCC CHECKDB 偵測到損毀錯誤時，就會在 SQL Server LOG 目錄中建立堆疊傾印（SQLDump<nnnn>.txt、SQLDump<nnnn>.log、SQLDump<nnnn>.mdmp）。當 SQL Server 的執行個體已啟用「功能使用方式」資料收集及「錯誤報告」功能時，這個檔案會自動轉送到 Microsoft。收集的資料是用來提升 SQL Server 功能。傾印檔案包含 DBCC CHECKDB 命令的結果，以及其他診斷輸出。存取權會限制為 SQL Server 服務帳戶及系統管理員角色的成員。依預設，系統管理員 (sysadmin) 角色包含 Windows BUILTIN\Administrators 群組及本機系統管理員群組的所有成員。如果資料收集程序失敗，DBCC 命令不會失敗。

解決錯誤

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

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

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

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

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

注意

您無法在使用者交易內以緊急模式執行 DBCC CHECKDB 命令，並在執行后回復交易。

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

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

警告

REPAIR_ALLOW_DATA_LOSS 選項可能會導致比從上次已知良好的備份還原時更多的資料遺失。請參閱 REPAIR_ALLOW_DATA_LOSS 的資料遺失警告

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

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

具有REPAIR_ALLOW_DATA_LOSS的資料遺失警告

REPAIR_ALLOW_DATA_LOSS 選項是受支援的 SQL Server 功能。不過，它不一定是將資料庫帶入實體一致狀態的最佳選項。如果成功，REPAIR_ALLOW_DATA_LOSS 選項可能會導致某些數據遺失。

事實上，這可能會導致比使用者從上次已知的良好備份復原資料庫更嚴重的數據遺失。 Microsoft 一律建議使用者從上次已知良好的備份還原，作為修復 DBCC CHECKDB 所報告錯誤的主要方法。

REPAIR_ALLOW_DATA_LOSS 選項無法取代從已知良好的備份還原方法。這是緊急 最後手段 選項，只有在從備份還原 不可能 時，才建議使用。

重建記錄檔之後，沒有完整的 ACID 保證。

重建記錄檔之後，會自動執行 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 選項：

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

結果集

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.

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

The command(s) completed successfully.

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

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.

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

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.

權限

需要成為 系統管理員 固定伺服器角色或 db_owner 固定資料庫角色的成員。

範例

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

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

-- Check the current database.
DBCC CHECKDB;
GO

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

B. 檢查目前的資料庫，隱藏參考訊息

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

DBCC CHECKDB WITH NO_INFOMSGS;
GO

共用方式為

DBCC CHECKDB (Transact-SQL)

語法

引數

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

備註

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

了解資料庫的相容性層級

內部資料庫快照集

從 SQL Server 2014 開始，DBCC CHECKDB 如何建立內部快照集資料庫

檢查並修復 FILESTREAM 資料

最佳做法

平行檢查物件

了解 DBCC 錯誤訊息

錯誤報告

解決錯誤

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

具有REPAIR_ALLOW_DATA_LOSS的資料遺失警告

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

結果集

權限

範例

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

B. 檢查目前的資料庫，隱藏參考訊息

意見反應

其他資源

共用方式為

DBCC CHECKDB (Transact-SQL)

語法

引數

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

備註

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

了解資料庫的相容性層級

內部資料庫快照集

從 SQL Server 2014 開始，DBCC CHECKDB 如何建立內部快照集資料庫

檢查並修復 FILESTREAM 資料

最佳做法

平行檢查物件

了解 DBCC 錯誤訊息

錯誤報告

解決錯誤

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

具有REPAIR_ALLOW_DATA_LOSS的資料遺失警告

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

結果集

權限

範例

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

B. 檢查目前的資料庫，隱藏參考訊息

相關內容

意見反應

其他資源