DBCC CHECKTABLE (Transact-SQL)

語法

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , EXTENDED_LOGICAL_CHECKS ] 
          [ , NO_INFOMSGS ]
          [ , TABLOCK ] 
          [ , ESTIMATEONLY ] 
          [ , { PHYSICAL_ONLY | DATA_PURITY } ] 
        }
    ]

引數

• table_name | view_name
  這是要執行完整性檢查的資料表或索引檢視表。資料表或檢視表名稱必須符合識別碼的規則。

• NOINDEX
  指定不應該執行使用者資料表之非叢集索引的大量檢查。這會減少整體的執行時間。NOINDEX 不會影響系統資料表，因為所有系統資料表索引一律會執行完整性檢查。

• index_id
  這是要執行完整性檢查的索引識別 (ID) 碼。如果指定了 index_id，DBCC CHECKTABLE 只會針對該索引及堆積或叢集索引執行完整性檢查。

• REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
  指定 DBCC CHECKTABLE 修復找到的錯誤。若要使用修復選項，資料庫必須在單一使用者模式中。

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

  • REPAIR_FAST
    維護語法的目的僅在於回溯相容性。不會執行任何修復動作。

  • REPAIR_REBUILD
    執行不可能造成資料遺失的修復，這可包括快速修復 (例如，修復非叢集索引中遺失的資料列) 以及更耗時的修復 (例如，重建索引)。

    REPAIR_REBUILD 不會修復與 FILESTREAM 資料有關的錯誤。

  [!附註]

  最好不要使用這些 REPAIR 選項。若要修復錯誤，我們建議您從備份中還原。修復作業並不考慮資料表或資料表之間的任何條件約束。如果指定的資料表涉及一或多項條件約束，建議您在修復作業之後，執行 DBCC CHECKCONSTRAINTS。如果您必須使用 REPAIR，請執行不含修復選項的 DBCC CHECKTABLE 來尋找要使用的修復層級。如果您要使用 REPAIR_ALLOW_DATA_LOSS 層級，建議您在搭配這個選項執行 DBCC CHECKTABLE 之前，先備份資料庫。

• ALL_ERRORMSGS
  顯示沒有限制的錯誤數目。在 SQL Server 2008 Service Pack 1 (SP1) 中，預設會顯示所有錯誤訊息。指定或省略這個選項沒有任何作用。在舊版 SQL Server 中 (除了 SQL Server 2005 SP3)，如果未指定 ALL_ERRORMSGS，則只會顯示每個物件的前 200 個錯誤訊息。

• EXTENDED_LOGICAL_CHECKS
  如果相容性層級為 100 (SQL Server 2008) 或更高，則會針對索引檢視表、XML 索引和空間索引 (如果有的話) 執行邏輯一致性檢查。

  如需詳細資訊，請參閱本主題稍後「備註」一節中的「對索引執行邏輯一致性檢查」。

• NO_INFOMSGS
  隱藏所有參考訊息。

• TABLOCK
  使 DBCC CHECKTABLE 取得共用資料表鎖定，而不使用內部資料庫快照集。TABLOCK 會使 DBCC CHECKTABLE 在負荷很重的情況下，仍能在資料表上執行得比較快，但當 DBCC CHECKTABLE 在執行中，它會降低資料表上所能使用的並行性。

• ESTIMATEONLY
  顯示設定所有其他指定的選項，以執行 DBCC CHECKTABLE 所需要的 tempdb 預估空間量。

• PHYSICAL_ONLY
  將檢查限制於頁面實體結構、記錄標頭和 B 型樹狀目錄之實體結構的完整性。這個項目是專為提供資料表實體一致性的小型負擔檢查而設計，這項檢查也能夠偵測到損毀的頁面以及可能危及資料的一般硬體故障。完整執行 DBCC CHECKTABLE 所需要的時間可能比舊版多許多。這個行為發生的原因如下：

  • 邏輯檢查更完整。

  • 部分要檢查的基礎結構更複雜。

  • 導入了許多新的檢查，以包含新的功能。

  因此，使用 PHYSICAL_ONLY 選項可能使大型資料表 DBCC CHECKTABLE 的執行階段縮短許多，因此，建議您在實際系統上經常使用它。我們仍建議您定期完整執行 DBCC CHECKTABLE。執行這些動作的頻率取決於個別商務和實際執行環境特有的因素。PHYSICAL_ONLY 一律隱含 NO_INFOMSGS，而且不允許使用任何修復選項。

  [!附註]

  指定 PHYSICAL_ONLY 會造成 DBCC CHECKTABLE 略過 FILESTREAM 資料的所有檢查。

• DATA_PURITY
  使 DBCC CHECKTABLE 檢查資料表，找出無效或超出範圍的資料行值。例如，DBCC CHECKTABLE 偵測到的資料行包含大於或小於 datetime 資料類型可接受範圍的日期和時間值；或者，decimal 或近似數值資料類型的資料行包含無效的小數位數或有效位數值。

  對於在 SQL Server 2005 及更新版本中建立的資料庫而言，預設會啟用資料行值的完整性檢查，而不需要 DATA_PURITY 選項。對於從舊版 SQL Server 升級的資料庫，您可以使用 DBCC CHECKTABLE WITH DATA_PURITY 尋找並更正特定資料表的錯誤，不過，必須先在毫無錯誤的情況下完成對資料庫執行 DBCC CHECKDB WITH DATA_PURITY，否則依預設不對資料表啟用資料行值檢查。此後，依預設 DBCC CHECKDB 和 DBCC CHECKTABLE 會檢查資料行值的完整性。

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

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

備註

DBCC CHECKTABLE 會檢查指定之資料表的下列項目：

• 已正確連結索引、in-row、LOB 和資料列溢位資料頁面。

• 索引符合正確的排序次序。

• 指標一致。

• 每個頁面中的資料都是合理的，其中包括計算資料行。

• 頁面位移合理。

• 基底資料表的每個資料列在每個非叢集索引中都有相符的資料列，反之亦然。

• 資料分割資料表或索引中的每個資料列都在正確的資料分割中。

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

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

內部資料庫快照集

檢查及修復 FILESTREAM 資料

平行檢查物件

了解 DBCC 錯誤訊息

錯誤報告

解決錯誤

結果集

DBCC CHECKTABLE 會傳回下列結果集。如果您只指定了資料表名稱或任何選項，就會傳回相同的結果集。

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

如果指定了 ESTIMATEONLY 選項，DBCC CHECKTABLE 會傳回下列結果集：

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

權限

使用者必須擁有資料表，或者為 sysadmin 固定伺服器角色、db_owner 固定資料庫角色或 db_ddladmin 固定資料庫角色的成員。

範例

A. 檢查特定資料表

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

B. 執行資料表的低負擔檢查

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C. 檢查特定索引

USE AdventureWorks;
GO
DECLARE @indid int;
SET @indid = (SELECT index_id 
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ("Production.Product", @indid);

變更記錄

請參閱

參考

概念

其他資源