DBCC CHECKDB (Transact-SQL)

更新 : 2008 年 11 月 17 日

次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。

• データベースに対して DBCC CHECKALLOC を実行。
• データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
• データベースに対して DBCC CHECKCATALOG を実行。
• データベース内にあるすべてのインデックス付きビューの内容を検証。
• データベースの 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 ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

引数

• database_name | database_id | 0
  整合性チェックを実行するデータベースの名前または ID を指定します。指定しない場合、または 0 を指定した場合は、現在のデータベースが使用されます。データベース名は、識別子の規則に従っている必要があります。

• NOINDEX
  ユーザー テーブルの非クラスタ化インデックスの集中チェックを実行しないように指定します。これにより、全体の実行時間が短縮されます。整合性チェックは、常にすべてのシステム テーブルのインデックスに対して実行されるため、NOINDEX はシステム テーブルに対しては無効です。

• REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
  検出されたエラーを DBCC CHECKDB が修復するように指定します。修復オプションを使用するには、指定するデータベースがシングル ユーザー モードになっている必要があります。以下の修復オプションを使用できます。**

  • REPAIR_ALLOW_DATA_LOSS
    報告されたすべてのエラーの修復を試みます。これらの修復を実行すると、データが失われることがあります。
  • REPAIR_FAST
    旧バージョンとの互換性のためにのみ、構文が用意されています。修復操作は実行されません。
  • REPAIR_REBUILD
    非クラスタ化インデックスの追加キーの修復など小規模で時間のかからない修復操作と、インデックスの再構築など時間のかかる修復操作の両方を実行します。これらの修復によってデータが失われるリスクはありません。

  重要 :
  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 個まで表示されます。tempdb データベースから生成されるメッセージを除き、エラー メッセージは、オブジェクト ID を基準として並べ替えられます。

  SQL Server Management Studio では、返される最大エラー メッセージ番号は 1000 です。ALL_ERRORMSGS を指定する場合は、必要に応じて Management Studio で DBCC CHECKDB を複数回実行し、エラーの完全な一覧を取得します。sqlcmd ユーティリティを使用して DBCC コマンドを実行するか、SQL Server のエージェント ジョブをスケジュールして DBCC コマンドを実行し、ファイルに出力することをお勧めします。どちらの方法でも、コマンドを 1 回実行するとすべてのエラー メッセージが出力されます。

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

• TABLOCK
  DBCC CHECKDB が、内部データベースのスナップショットを使用せずに、ロックを取得します。これにはデータベースの短期の排他 (X) ロックも含まれます。TABLOCK の作用によって負荷の高いデータベースでも DBCC CHECKDB の実行速度が速くなりますが、DBCC CHECKDB の実行中はデータベースでの同時実行性が低下します。ロックの詳細については、「ロック モード」を参照してください。

  TABLOCK では実行されるチェックが制限されます。DBCC CHECKCATALOG はデータベースに対して実行されず、Service Broker データは検証されません。

• ESTIMATEONLY
  必要な他のオプションをすべて指定した状態で、DBCC CHECKDB の実行時に必要となる tempdb 領域の予測サイズを表示します。実際のデータベースのチェックは行われません。

• PHYSICAL_ONLY
  チェック内容を、ページとレコード ヘッダーの物理構造の整合性、およびデータベースの B-Tree と割り当ての物理構造の一貫性に限定します。このチェックは、データベースの物理的一貫性に関する低オーバーヘッド チェックを提供するように設計されているため、ユーザーのデータが損傷する可能性のある破損ページやチェックサム エラー、および一般的なハードウェア障害も検出できます。PHYSICAL_ONLY を指定した場合は常に NO_INFOMSGS も暗黙的に指定されるため、修復オプションを同時指定することはできません。

• 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 のトラブルシューティング」を参照してください。

結果セット

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.

NO_INFOMSGS を指定した場合、DBCC CHECKDB は以下の結果セット (メッセージ) を返します。

The command(s) completed successfully.

PHYSICAL_ONLY を指定した場合、DBCC CHECKDB は以下の結果セットを返します。

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.

ESTIMATEONLY を指定した場合、DBCC CHECKDB は以下の結果セットを返します。

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.

解説

以前のバージョンの SQL Server の場合、テーブルごと、およびインデックスごとの行数やページ数の値が正しくならないことがあります。特定の状況では、これらの値が負の値になることもあります。SQL Server 2005 では、値が常に正しく保たれます。したがって、SQL Server 2005 上で作成されたデータベースに間違った行数やページ数が含まれることはありませんが、SQL Server 2005 にアップグレードされたデータベースには含まれる可能性があります。この場合、データベースに格納されているデータが破損しているわけではありません。DBCC CHECKDB は拡張され、これらの値が 1 つでも負の値になると検出されるようになっています。負の値が検出されると、DBCC CHECKDB の出力に警告が表示され、推奨される解決方法として DBCC UPDATEUSAGE を実行するよう示されます。この問題は、データベースを SQL Server 2005 にアップグレードしたことにより発生したように見えますが、間違った値はアップグレードの前から存在しています。

DBCC CHECKDB は、無効なインデックスについては検査しません。無効なインデックスの詳細については、「インデックスの無効化」を参照してください。

ユーザー定義型がバイト順としてマークされている場合、シリアル化されたユーザー定義型は 1 つだけ存在する必要があります。シリアル化されたバイト順のユーザー定義型が一貫して存在していない場合、DBCC CHECKDB の実行中にエラー 2537 が発生します。詳細については、「ユーザー定義型の要件」を参照してください。

Resource データベースはシングル ユーザー モードでしか修正できないため、このデータベースに対して DBCC CHECKDB コマンドを直接実行することはできません。ただし、DBCC CHECKDB を master データベースに対して実行すると、内部的に次の CHECKDB が Resource データベースに対して実行されます。このため、DBCC CHECKDB が追加の結果を返す場合があります。このコマンドでは、オプションが設定されていないか、PHYSICAL_ONLY または ESTIMATEONLY オプションが設定されている場合に、追加の結果セットが返されます。

SP2 より前のバージョンの SQL Server 2005 で DBCC CHECKDB を実行すると、SQL Server インスタンスのプラン キャッシュが消去されます。プラン キャッシュが消去されると、後続のすべての実行プランが再コンパイルされ、場合によっては、クエリ パフォーマンスが一時的に急激に低下します。SP2 では、DBCC CHECKDB を実行してもプラン キャッシュは消去されません。

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

DBCC CHECKDB では、チェックの実行に必要なトランザクションの一貫性を得るため、内部データベース スナップショットを使用します。これにより、コマンド実行時のブロックや同時実行の問題を回避できます。詳細については、「データベース スナップショットのスパース ファイルのサイズについて」、および「DBCC (Transact-SQL)」の「DBCC 内部データベース スナップショットの使用」を参照してください。スナップショットを作成できない場合や TABLOCK が指定されている場合、DBCC CHECKDB はロックを取得して必要な一貫性を実現します。この場合、割り当てのチェックを行うための排他データベース ロックと、テーブルのチェックを行うための共有テーブル ロックが必要です。

DBCC CHECKDB を master に対して実行し、内部データベース スナップショットを作成できない場合、DBCC CHECKDB は失敗します。

tempdb に対して DBCC CHECKDB を実行しても、割り当てまたはカタログのチェックは行われず、共有テーブル ロックを取得してテーブルのチェックを行う必要があります。これは、パフォーマンス上の理由から、データベースのスナップショットが tempdb では利用できないためです。つまり、必要なトランザクションの一貫性を確保できません。

推奨事項

SQL Server 2005 では、オプションを指定せずに DBCC CHECKDB を実行すると、以前のバージョンよりかなり時間がかかることがあります。原因は次のとおりです。

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

このため、実稼働システムで頻繁に使用する場合は PHYSICAL_ONLY オプションを使用することをお勧めします。PHYSICAL_ONLY を使用すると、大規模データベースでの DBCC CHECKDB の実行時間を大幅に短縮できます。また、定期的に、オプションを指定せずに DBCC CHECKDB を実行することもお勧めします。DBCC CHECKDB を実行する頻度は、個々の業務とその運用環境によって変わります。

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

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

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

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

エラー報告の使用

SQL Server 2005 Service Pack 1 では、DBCC CHECKDB により破損エラーが検出されると必ず、ダンプ ファイル (SQLDUMPnnnn.txt) が SQL Server の LOG ディレクトリに生成されます。機能の使用状況データ収集とエラー報告機能が SQL Server インスタンスに対して有効になっている場合、ダンプ ファイルは自動的に Microsoft に転送されます。収集されたデータは SQL Server の機能向上のために使用されます。詳細については、「エラー レポートと使用状況レポートの設定」を参照してください。

このダンプ ファイルには、DBCC CHECKDB コマンドの結果と追加の診断出力が含まれます。ダンプ ファイルにアクセスできるのは、SQL Server サービス アカウントとロール sysadmin のメンバだけです。既定では、sysadmin ロールには Windows の BUILTIN\Administrators グループとローカルの管理者グループのすべてのメンバが含まれます。データ収集プロセスが失敗しても、DBCC コマンドは失敗しません。

エラーの解決

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

状況によっては、データベースに、列のデータ型に対して有効ではない値や範囲外の値が入力されていることがあります。SQL Server 2000 では、DBCC CHECKDB は、これらの列の値に関する範囲や整合性のチェックを行いません。それに対し、SQL Server 2005 の DBCC CHECKDB は、すべての列のデータ型について有効ではない列の値を検出します。したがって、以前のバージョンの SQL Server からアップグレードしたデータベースに対して DATA_PURITY オプションを指定して DBCC CHECKDB を実行すると、以前から存在していた列の値のエラーが検出される場合があります。SQL Server 2005 ではこれらのエラーを自動的に修復することはできないため、列の値を手動で更新する必要があります。CHECKDB でこのようなエラーが検出されると、CHECKDB は警告 (エラー番号 2570) を返し、影響を受ける行を特定してエラーを手動で修正するための情報を示します。

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

データベース緊急モードでのエラーの解決

ALTER DATABASE ステートメントによってデータベースが緊急モードに設定されている場合、REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB を実行すると、データベースに対していくつかの特別な修復を実行できます。このような修復により、通常は復旧不可能なデータベースを、物理的な一貫性のある状態でオンラインに戻すことができる場合があります。このような修復は、バックアップからデータベースを復元できない場合にのみ、最終的な手段として使用してください。データベースが緊急モードに設定されている場合、データベースは READ_ONLY になり、ログ記録は無効になります。加えて、固定サーバー ロール sysadmin のメンバ以外はデータベースにアクセスできません。

メモ :
ユーザー トランザクション内で DBCC CHECKDB コマンドを緊急モードで実行したり、実行後にトランザクションをロールバックすることはできません。

データベースが緊急モードのときに、REPAIR_ALLOW_DATA_LOSS 句を指定して DBCC CHECKDB を実行した場合は、次の処理が行われます。

• DBCC CHECKDB では、I/O エラーまたはチェックサム エラーが原因でアクセス不可とマークされたページが、エラーが発生しなかった場合と同様に使用されます。これにより、データベースからのデータ復旧の可能性が高くなります。
• DBCC CHECKDB では、標準的なログ ベースの復旧方法により、データベースの復旧が試行されます。
• トランザクション ログが壊れているためにデータベース復旧が失敗した場合、トランザクション ログは再構築されます。ただし、トランザクション ログの再構築の結果、トランザクションの一貫性が失われる場合があります。

DBCC CHECKDB コマンドが正常に終了した場合、データベースでは物理的な一貫性が保たれ、データベースの状態は ONLINE に設定されます。ただし、データベースにはトランザクション上一貫しない部分が 1 つ以上含まれる可能性があります。DBCC CHECKCONSTRAINTS コマンドを実行してビジネス ロジックの不備を確認し、直ちにデータベースをバックアップすることをお勧めします。

DBCC CHECKDB コマンドが失敗した場合、データベースを修復することはできません。

レプリケートされたデータベースでの、REPAIR_ALLOW_DATA_LOSS を指定した DBCC CHECKDB の実行

REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行すると、レプリケーションで使用されるユーザー データベース (パブリケーション データベースおよびサブスクリプション データベース) とディストリビューション データベースに影響が生じる場合があります。パブリケーション データベースとサブスクリプション データベースには、パブリッシュされたテーブルとレプリケーション メタデータ テーブルが含まれます。これらのデータベースでは、次の問題が発生する可能性があります。

• パブリッシュされたテーブル。破損したユーザー データを修復するため CHECKDB 処理によって実行されるアクションが、レプリケートされない場合があります。
  • マージ レプリケーションではトリガを使用して、パブリッシュされたテーブルに対する変更を追跡します。CHECKDB 処理で行が挿入、更新、または削除された場合、トリガは起動しません。このため、変更はレプリケートされません。
  • トランザクション レプリケーションではトランザクション ログを使用して、パブリッシュされたテーブルに対する変更を追跡します。その後、ログ リーダー エージェントは変更をディストリビューション データベースに移動します。DBCC 修復の一部は、ログには記録されますが、ログ リーダー エージェントでレプリケートできません。たとえば、CHECKDB 処理によってデータ ページの割り当てが解除された場合、ログ リーダー エージェントではこの処理が DELETE ステートメントに変換されません。このため、変更はレプリケートされません。
• レプリケーション メタデータ テーブル。破損したレプリケーション メタデータ テーブルを修復するため CHECKDB 処理で実行されるアクションでは、レプリケーションの削除と再構成が必要になります。

ユーザー データベースまたはディストリビューション データベースで、REPAIR_ALLOW_DATA_LOSS オプションを指定して DBCC CHECKDB コマンドを実行する必要がある場合は、次の手順に従います。

1. システムを停止します。データベースの操作と、レプリケーション トポロジの他のすべてのデータベースの利用を停止した後、すべてのノードの同期を試行します。詳細については、「レプリケーション トポロジを停止する方法 (レプリケーション Transact-SQL プログラミング)」を参照してください。
2. DBCC CHECKDB を実行します。
3. DBCC CHECKDB レポートで、ディストリビューション データベースの任意のテーブルまたはユーザー データベースのレプリケーション メタデータ テーブルの修復が示されている場合は、レプリケーションを削除して再構成します。詳細については、「レプリケーションの削除」を参照してください。
4. DBCC CHECKDB レポートで、レプリケートされたテーブルの修復が示されている場合は、データ検証を実行して、パブリケーション データベースとサブスクリプション データベースのデータ間に違いがあるかどうかを確認します。詳細については、「パブリッシャとサブスクライバのデータが一致しない」を参照してください。

権限

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

参照

関連項目

DBCC (Transact-SQL)
sp_helpdb (Transact-SQL)
システム テーブル (Transact-SQL)

その他の技術情報

物理データベース アーキテクチャ
データベース スナップショットのスパース ファイルのサイズについて
インデックス付きビューの DBCC エラーに関するトラブルシューティング
DBCC CHECKDB のパフォーマンスの最適化

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴