DBCC CHECKTABLE (Transact-SQL)

[アーティクル]
04/26/2023

適用対象:SQL Server Azure SQL Database Azure SQL Managed Instance

テーブルまたはインデックス付きビューを構成するすべてのページおよび構造の整合性チェックを行います。

構文

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

Note

SQL Server 2014 以前の Transact-SQL 構文を確認するには、以前のバージョンのドキュメントを参照してください。

引数

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

データ損失の可能性がない修復を実行します。これには、非クラスター化インデックスの存在しない行の修復など時間のかからない修復操作と、インデックスの再構築など時間のかかる修復操作が含まれます。

この引数では、FILESTREAM データに関係するエラーは修復されません。

重要

REPAIR オプションは、最後の手段としてのみ使用してください。エラーの修復では、バックアップから復元することをお勧めします。修復操作では、テーブルまたはテーブル間に制約があっても考慮されません。指定したテーブルに 1 つでも関連する制約がある場合は、修復操作の後に DBCC CHECKCONSTRAINTS を実行することをお勧めします。 REPAIR を使用する必要がある場合は、修復オプションを指定せずに DBCC CHECKTABLE を実行して、使用する修復レベルを確認してください。 REPAIR_ALLOW_DATA_LOSS レベルを使用する場合は、このオプションを指定して DBCC CHECKTABLE を実行する前に、データベースをバックアップすることをお勧めします。

ALL_ERRORMSGS

エラーを無制限に表示します。既定では、すべてのエラーメッセージが表示されます。このオプションを指定しても省略しても影響はありません。

EXTENDED_LOGICAL_CHECKS

互換性レベルが SQL Server 2008 (10.0.x) で導入された 100 である場合、インデックス付きビュー、XML インデックス、空間インデックスについて (存在する場合)、論理的な整合性チェックを実行します。

詳細については、この記事で後述する「解説」の「インデックスに対する論理的な整合性チェックの実行」を参照してください。

NO_INFOMSGS

すべての情報メッセージを表示しないようにします。

TABLOCK

DBCC CHECKTABLE で内部データベースのスナップショットを使用するのではなく、共有テーブルロックを取得します。 TABLOCK を使用すると、負荷の高いテーブルでも DBCC CHECKTABLE の実行速度が速くなりますが、DBCC CHECKTABLE の実行中はテーブルでのコンカレンシーが低下します。

ESTIMATEONLY

必要な他のオプションをすべて指定した状態で、DBCC CHECKTABLE の実行時に必要となる tempdb 領域の予測容量を表示します。

PHYSICAL_ONLY

チェック内容を、ページ、レコードヘッダー、および B ツリーの物理構造の整合性に限定します。テーブルの物理的一貫性に関する低オーバーヘッドチェックを提供するように設計されているため、このチェックではデータが損傷する可能性のある破損ページおよび一般的なハードウェア障害も検出できます。完全な DBCC CHECKTABLE を実行すると、以前のバージョンよりはるかに時間がかかることがあります。この現象は次の原因により発生します。

論理チェックの対象範囲が広がった。
チェック対象の、基になる構造の一部が複雑になった。
新機能を含めるために多数の新しいチェックが導入された。

Note

SQL Server のドキュメントでは、一般にインデックスに関して B ツリーという用語が使用されます。行ストアインデックスで、SQL Server によって B+ ツリーが実装されます。これは、列ストアインデックスやメモリ内データストアには適用されません。詳細については、「SQL Server と Azure SQL のインデックスのアーキテクチャとデザインガイド」を参照してください。

したがって、大規模なテーブルでは、PHYSICAL_ONLY オプションを使用すると DBCC CHECKTABLE の実行時間が大幅に短縮されることがあるため、実稼働システムで頻繁に使用する場合はこのオプションを使用することをお勧めします。ただし、完全な DBCC CHECKTABLE を定期的に実行することもお勧めします。実行する頻度は、それぞれの業務環境や運用環境に固有の要因によって異なります。 PHYSICAL_ONLY によって NO_INFOMSGS も常に暗黙的に指定されるため、修復オプションを同時指定することはできません。

Note

PHYSICAL_ONLY を指定すると、DBCC CHECKTABLE で FILESTREAM データのチェックがすべてスキップされるようになります。

DATA_PURITY

DBCC CHECKTABLE によって、テーブル内に無効な列値または範囲外の列値が含まれていないかチェックされます。たとえば、DBCC CHECKTABLE により、datetime データ型の許容範囲外となる日時の値を含む列や、小数点以下桁数または有効桁数の値が有効ではない decimal または概数データ型の列が検出されます。

列の値の整合性チェックは既定で有効になっているため、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 を指定した場合は、列の整合性チェックは行われません。

MAXDOP

適用対象: SQL Server 2014 (12.x) Service Pack 2 以降のバージョン。

ステートメントの sp_configure の max degree of parallelism 構成オプションをオーバーライドします。 MAXDOP では、sp_configure で構成されている値を超えることができます。 MAXDOP では、Resource Governor で構成されている値を超えると、データベースエンジンは、「ALTER WORKLOAD GROUP (Transact-SQL)」に記載のリソースガバナーの MAXDOP 値を使用します。 MAXDOP クエリヒントを使用している場合は、max degree of parallelism 構成オプションで使用されるすべての意味ルールを適用できます。詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

Note

MAXDOP が 0 に設定されている場合、サーバーでは最大限の並列処理が実行されます。

解説

Note

データベース内のすべてのテーブルに対して DBCC CHECKTABLE を実行するには、DBCC CHECKDB を使用します。

指定したテーブルについて、DBCC CHECKTABLE によって次の項目がチェックされます。

インデックス、行内、LOB、および行オーバーフローデータの各ページが正しくリンクされていること。
インデックスが正しい並べ替え順序で並んでいること。
ポインターに一貫性があること。
各ページ上のデータが、計算列も含め、適切であること。
ページオフセットが適切であること。
ベーステーブルと各非クラスター化インデックスのすべての行がそれぞれに対応していること。
パーティションテーブルやパーティションインデックスのすべての行が正しいパーティションにあること。
FILESTREAM を使用して varbinary(max) データをファイルシステムに格納する場合のファイルシステムとテーブル間でのリンクレベルの一貫性。

インデックスに対する論理的な整合性チェックの実行

インデックスに対する論理的な一貫性チェックは、データベースの互換性レベルによって次のように異なります。

互換性レベルが 100 (SQL Server 2008 (10.0.x)) 以上の場合:
- NOINDEX が指定されていない場合、DBCC CHECKTABLE を使用すると、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な整合性と論理的な整合性の両方がチェックされます。ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。
- WITH EXTENDED_LOGICAL_CHECKS が指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。 NOINDEX も指定されている場合は、論理チェックのみが実行されます。
  
  この論理的な一貫性のチェックでは、インデックスオブジェクトの内部インデックステーブルが参照先のユーザーテーブルと照合されます。行の不整合を検出するために、内部テーブルとユーザーテーブルの完全な積集合を実行する内部クエリが作成されます。このクエリを実行するとパフォーマンスに多大な影響を及ぼす可能性があり、その進行状況は追跡できません。したがって、物理的な破損とは無関係のインデックスの問題があると考えられる場合、またはページレベルのチェックサムがオフになっており、列レベルのハードウェアの破損が考えられる場合にのみ、WITH EXTENDED_LOGICAL_CHECKS を指定することをお勧めします。
- インデックスがフィルター選択されたインデックスである場合、DBCC CHECKTABLE で整合性チェックを実行して、インデックスエントリがフィルター述語に適合していることを確認します。
SQL Server 2016 (13.x) 以降では、コストの高い式の評価を避けるため、既定では、保存される計算列、UDT 列、およびフィルター選択されたインデックスへの追加のチェックは実行されません。この変更により、これらのオブジェクトを含むデータベースに対する CHECKTABLE の時間が大幅に短縮されます。ただし、これらのオブジェクトの物理的な整合性チェックは常に実行されます。 EXTENDED_LOGICAL_CHECKS オプションが指定されている場合にのみ、既存の論理チェック (インデックス付きビュー、XML インデックス、および空間インデックス) に加え、EXTENDED_LOGICAL_CHECKS オプションの一部として式の評価が行われます。
互換性レベルが 90 (SQL Server 2005 (9.x)) 以下で NOINDEX が指定されていない場合、DBCC CHECKTABLE は、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスター化インデックスおよび XML インデックスについて、物理的および論理的の両方の整合性チェックが実行されます。空間インデックスはサポートされません。

データベースの互換性レベルを調べるには

データベースの互換性レベルの表示または変更

内部データベーススナップショット

DBCC CHECKTABLE では、内部データベースのスナップショットを使用して、これらのチェックを実行するために必要なトランザクションの整合性を確保します。詳細については、「データベーススナップショットのスパースファイルのサイズを表示する方法 (Transact-SQL)」と、「DBCC (Transact-SQL)」の「DBCC 内部データベーススナップショットの使用」セクションを参照してください。

スナップショットを作成できない場合や TABLOCK が指定されている場合、DBCC CHECKTABLE は共有テーブルロックを取得して必要な整合性を確保します。

Note

tempdb に対して DBCC CHECKTABLE を実行する場合、共有テーブルロックを取得する必要があります。これは、パフォーマンス上の理由から、データベースのスナップショットが tempdb では利用できないためです。つまり、必要なトランザクションの一貫性を実現できないためです。

FILESTREAM データの確認と修復

データベースとテーブルに対して FILESTREAM が有効になっている場合、varbinary(max) バイナリラージオブジェクト (BLOB) をファイルシステムに格納することもできます。 BLOB をファイルシステムに格納するテーブルに対して DBCC CHECKTABLE を使用する場合は、DBCC によって、ファイルシステムとデータベースの間でのリンクレベルの整合性がチェックされます。

たとえば、テーブルに FILESTREAM 属性を使用する varbinary(max) 列が含まれている場合、DBCC CHECKTABLE は、ファイルシステムのディレクトリおよびファイルと、テーブルの行、列、および列の値とが一対一でマップされていることをチェックします。 REPAIR_ALLOW_DATA_LOSS オプションを指定すると、DBCC CHECKTABLE で破損を修復できます。 FILESTREAM の破損を修復するため、DBCC はファイルシステムデータがないテーブル行をすべて削除し、テーブルの行、列、および列の値にマップされないディレクトリとファイルをすべて削除します。

オブジェクトの並列チェック

DBCC CHECKTABLE の既定では、オブジェクトの並列チェックが実行されます。並列処理の次数は、クエリプロセッサによって自動的に決定されます。並列処理の最大限度は、並列クエリと同様に構成します。 DBCC チェックに利用できるプロセッサの最大数を制限するには、sp_configure を使用します。詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

並列チェックはトレースフラグ 2528 を使用して無効にできます。詳細については、トレースフラグ (Transact-SQL)に関する記事を参照してください。

Note

DBCC CHECKTABLE の操作中、バイト順のユーザー定義型の列に保存されるバイトは、シリアル化されたユーザー定義型の計算値と同じである必要があります。同じでない場合は、DBCC CHECKTABLE ルーチンで整合性エラーが報告されます。

Note

この機能は、 SQL Serverのすべてのエディションで使用できるわけではありません。詳細については、「SQL Server 2022 の各エディションとサポートされている機能」の「RDBMS の管理の容易性」で並列整合性チェックをご確認ください。

DBCC エラーメッセージについて

DBCC CHECKTABLE コマンドの終了後、メッセージが SQL Server エラーログに書き込まれます。 DBCC コマンドが正常に実行された場合、メッセージでは正常完了とコマンド実行時間が示されます。エラーが発生して DBCC コマンドが完了前に停止した場合、メッセージではコマンドが終了したことと、状態の値、コマンド実行時間が示されます。次の表は、メッセージに含まれる可能性がある状態値の一覧と説明です。

State	説明
0	エラー番号 8930 が発生しました。メタデータの破損が原因で DBCC コマンドが終了しました。
1	エラー番号 8967 が発生しました。内部 DBCC エラーがあります。
2	緊急モードのデータベース修復中にエラーが発生しました。
3	メタデータの破損が原因で DBCC コマンドが終了しました。
4	アサートまたはアクセス違反が検出されました。
5	不明なエラーが発生し、DBCC コマンドが終了しました。

エラー報告

DBCC CHECKTABLE により破損エラーが検出されるたびに、ミニダンプファイル (SQLDUMP<nnnn>.txt) が SQL Server の LOG ディレクトリに生成されます。 機能の使用状況データ収集とエラー報告機能が SQL Server インスタンスに対して有効になっている場合、ダンプファイルは自動的に Microsoft に転送されます。収集されたデータは SQL Server の機能向上のために使用されます。

このダンプファイルには、DBCC CHECKTABLE コマンドの結果と追加の診断出力が含まれます。また、制限付きの随意アクセス制御リスト (DACL) が割り当てられます。アクセスが、SQL Server サービスアカウントと sysadmin ロールのメンバーに制限されます。既定では、sysadmin ロールには、Windows の builtin \administrators グループとローカルの管理者のグループのすべてのメンバーが含まれています。データ収集プロセスが失敗しても、DBCC コマンドは失敗しません。

エラーの解決

DBCC CHECKTABLE でエラーが報告された場合は、REPAIR オプションのいずれかを指定して実行するのではなく、データベースのバックアップからデータベースを復元することをお勧めします。バックアップが存在しない場合は、REPAIR を実行することによって、報告されたエラーを修正できます。使用する REPAIR オプションは、報告されたエラーの一覧の最後に指定されています。ただし、REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。

ユーザートランザクションを利用して修復を実行できるので、後からユーザーが変更をロールバックすることができます。修復をロールバックしたときは、データベースにエラーが残っているので、データベースをバックアップから復元する必要があります。すべての修復が完了したら、データベースをバックアップします。

結果セット

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. 特定のテーブルをチェックする

次の例では、AdventureWorks2022 データベースにある HumanResources.Employee テーブルのデータページの整合性をチェックします。

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. テーブルの低オーバーヘッドチェックを実行する

次の例では、AdventureWorks2022 データベースにある Employee テーブルの低オーバーヘッドチェックを実行します。

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. 特定のインデックスをチェックする

次の例では、sys.indexes にアクセスすることによって取得される特定のインデックスをチェックします。

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);

次の方法で共有

DBCC CHECKTABLE (Transact-SQL)

構文

引数

table_name | view_name

NOINDEX

index_id

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

解説

インデックスに対する論理的な整合性チェックの実行

データベースの互換性レベルを調べるには

内部データベーススナップショット

FILESTREAM データの確認と修復

オブジェクトの並列チェック

DBCC エラーメッセージについて

エラー報告

エラーの解決

結果セット

アクセス許可

例

A. 特定のテーブルをチェックする

B. テーブルの低オーバーヘッドチェックを実行する

C. 特定のインデックスをチェックする

関連項目

フィードバック

その他のリソース

次の方法で共有

DBCC CHECKTABLE (Transact-SQL)

構文

引数

table_name | view_name

NOINDEX

index_id

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

解説

インデックスに対する論理的な整合性チェックの実行

データベースの互換性レベルを調べるには

内部データベース スナップショット

FILESTREAM データの確認と修復

オブジェクトの並列チェック

DBCC エラー メッセージについて

エラー報告

エラーの解決

結果セット

アクセス許可

例

A. 特定のテーブルをチェックする

B. テーブルの低オーバーヘッド チェックを実行する

C. 特定のインデックスをチェックする

関連項目

フィードバック

その他のリソース

内部データベーススナップショット

DBCC エラーメッセージについて

B. テーブルの低オーバーヘッドチェックを実行する