次の方法で共有

DBCC CHECKTABLE (Transact-SQL)

  • [アーティクル]

更新 : 2008 年 11 月 17 日

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

トピック リンク アイコンTransact-SQL 構文表記規則

構文

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , 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
      非クラスタ化インデックスの追加キーの修復など小規模で時間のかからない修復操作と、インデックスの再構築など時間のかかる修復操作の両方を実行します。これらの修復によってデータが失われるリスクはありません。
    ms174338.note(ja-jp,SQL.90).gifメモ :
    REPAIR オプションは、最後の手段としてだけ使用してください。エラーの修復では、バックアップから復元することをお勧めします。修復操作では、テーブルまたはテーブル間に制約があっても考慮されません。指定されたテーブルに 1 つでも関連する制約がある場合は、修復操作の後に 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 個まで表示されます。
  • NO_INFOMSGS
    すべての情報メッセージを表示しないようにします。
  • TABLOCK
    DBCC CHECKTABLE が、内部データベースのスナップショットを使用するのではなく、共有テーブル ロックを取得します。TABLOCK の作用によって負荷の高いテーブルでも DBCC CHECKTABLE の実行速度が速くなりますが、DBCC CHECKTABLE の実行中はテーブルでの同時実行性が低下します。
  • ESTIMATEONLY
    必要な他のオプションをすべて指定した状態で、DBCC CHECKTABLE の実行時に必要となる tempdb 領域の予測サイズを表示します。

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

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

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

  • DATA_PURITY
    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 は次の結果セットを返します。テーブル名のみを指定した場合もその他のオプションを指定した場合も、同じ結果セットを返します。

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.

解説

DBCC CHECKTABLE は、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスタ化インデックスおよび XML インデックス (NOINDEX オプションが指定されていない場合) について、整合性をチェックします。データベース内のすべてのテーブルに対して DBCC CHECKTABLE を実行するには、DBCC CHECKDB を使用します。

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

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

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

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

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

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

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

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

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

ms174338.note(ja-jp,SQL.90).gifメモ :
DBCC CHECKTABLE の操作中、バイト順のユーザー定義型の列に保存されるバイトは、シリアル化されたユーザー定義型の計算値と同じである必要があります。同じでない場合は、DBCC CHECKTABLE ルーチンで一貫性エラーが報告されます。

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

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

状態 説明

0

エラー番号 8930 が発生しました。メタデータの破損が原因で DBCC コマンドが終了しました。

1

エラー番号 8967 が発生しました。内部 DBCC エラーがあります。

2

緊急モードのデータベース修復中にエラーが発生しました。

3

メタデータの破損が原因で DBCC コマンドが終了しました。

4

アサートまたはアクセス違反が検出されました。

5

不明なエラーが発生し、DBCC コマンドが終了しました。

エラー報告の使用

SQL Server 2005 Service Pack 1 (SP1) では、DBCC CHECKTABLE により破損エラーが検出されると必ず、小さいダンプ ファイル (SQLDUMPnnnn.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 オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。

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

権限

ユーザーはテーブルを所有しているか、固定サーバー ロール sysadmin、固定データベース ロール db_owner または固定データベース ロール db_ddladmin のメンバである必要があります。

例

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

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

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

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

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

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

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

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

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

参照

関連項目

DBCC (Transact-SQL)

その他の技術情報

テーブルとインデックスのアーキテクチャ
インデックス付きビューの DBCC エラーに関するトラブルシューティング

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース 履歴

2008 年 11 月 17 日
追加内容 :
  • ALL_ERRORMSGS の定義で SP3 における新しい機能を説明。

2006 年 12 月 12 日
追加内容 :
  • 「構文」と「引数」に、DATA_PURITY オプションを追加。

2006 年 4 月 14 日
追加内容 :
  • 「解説」に「エラー報告の使用」を追加。SP1 の新機能について説明。

2005 年 12 月 5 日
追加内容 :
  • ユーザー定義型に関する注記を追加。
変更内容 :
  • REPAIR_FAST の定義を修正。このオプションで修復操作は実行されないことを明記。
  • 構文を修正。
  • 例 C を修正。