DBCC CHECKDB (Transact-SQL)
適用対象:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
次の操作を実行し、指定したデータベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。
データベースに対して DBCC CHECKALLOC を実行。
データベース内にあるすべてのテーブルとビューに対して DBCC CHECKTABLE を実行。
データベースに対して DBCC CHECKCATALOG を実行。
データベース内にあるすべてのインデックス付きビューの内容を検証。
FILESTREAM を使用して varbinary(max) データをファイル システムに格納する場合のテーブルのメタデータとファイル システムのディレクトリおよびファイルの間のリンクレベルの一貫性を検証。
データベースの Service Broker データを検証。
つまり、DBCC CHECKALLOC、DBCC CHECKTABLE、または DBCC CHECKCATALOG コマンドを DBCC CHECKDB と別に実行する必要はありません。 これらのコマンドで実行されるチェックに関する詳細については、各コマンドの説明を参照してください。
DBCC CHECKDB は、メモリ最適化テーブルを含むデータベースでサポートされていますが、検証はディスク ベース テーブルでのみ行われます。 ただし、データベースのバックアップと復旧の一環として、メモリ最適化ファイル グループ内のファイルに対して CHECKSUM 検証が行われます。
DBCC 修復オプションはメモリ最適化テーブルに使用できないため、データベースを定期的にバックアップし、バックアップをテストする必要があります。 メモリ最適化テーブルでデータ整合性の問題が発生した場合は、最新の既知の良好なバックアップから復元する必要があります。
構文
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
整合性チェックを実行するデータベースの名前または ID。 値を指定しないか 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 データに関係するエラーは修復されません。
重要
REPAIR_* オプションのいずれかを使用した DBCC CHECKDB は完全にログに記録され、回復可能であるため、Microsoft では常に、ユーザーが操作の結果を受け入れることを確認できるように、トランザクション内の任意の REPAIR_* オプション (コマンドを実行する前に BEGIN TRANSACTION を実行) で DBCC CHECKDB を使用することをお勧めします。 ユーザーは、COMMIT TRANSACTION を実行して、修復操作によって行われたすべての作業をコミットできます。 ユーザーが操作の結果を受け入れたくない場合は、ROLLBACK TRANSACTION を実行して修復操作の効果を元に戻すことができます。
エラーの修復では、バックアップから復元することをお勧めします。 修復操作では、テーブル上またはテーブル間に存在する可能性のある制約は考慮されません。 指定したテーブルに 1 つでも関連する制約がある場合は、修復操作の後に DBCC CHECKCONSTRAINTS を実行することをお勧めします。
REPAIR_*を使用する必要がある場合は、修復オプションなしで DBCC CHECKDB 実行して、使用する修復レベルを見つけます。
REPAIR_ALLOW_DATA_LOSS レベルを使用する場合は、このオプションを指定して DBCC CHECKDB を実行する前に、データベースをバックアップすることをお勧めします。
ALL_ERRORMSGS
オブジェクトごとに、報告されているすべてのエラーを表示します。 既定では、すべてのエラー メッセージが表示されます。 このオプションを指定しても省略しても影響はありません。 tempdb データベースから生成されるメッセージを除き、エラー メッセージは、オブジェクト ID を基準として並べ替えられます。
EXTENDED_LOGICAL_CHECKS
互換性レベルが、SQL Server 2008 (10.0.x) で導入された 100 である場合、このオプションを使用すると、インデックス付きビュー、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」に記載されているリソース ガバナーの 値を使用します。
max degree of parallelism 構成オプションで使用されるすべてのセマンティック ルールは、MAXDOP クエリ ヒントを使用するときに適用できます。 詳細については、「サーバーの構成: 並列処理の最大次数」を参照してください。
警告
MAXDOP が 0 に設定されている場合、SQL Server は使用する max degree of parallelism を選択します。
解説
DBCC CHECKDB では、無効なインデックスは調べられません。 無効なインデックスの詳細については、「インデックスと制約を無効にする」を参照してください。
ユーザー定義型がバイト順としてマークされている場合、シリアル化されたユーザー定義型は 1 つだけ存在する必要があります。 シリアル化されたバイト順のユーザー定義型が一貫して存在していない場合、DBCC CHECKDB の実行中にエラー 2537 が発生します。 詳細については、「User-Defined タイプの登録 - 要件」を参照してください。
Resource データベースはシングル ユーザー モードでしか修正できないため、このデータベースに対して DBCC CHECKDB コマンドを直接実行することはできません。 ただし、DBCC CHECKDB を master データベースに対して実行すると、内部的に次の CHECKDB が Resource データベースに対して実行されます。 このため、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を使用すると、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な整合性と論理的な整合性の両方がチェックされます。 ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。WITH EXTENDED_LOGICAL_CHECKSが指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。 既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。NOINDEXも指定されている場合は、論理チェックのみが実行されます。
これらの論理整合性チェックでは、インデックス オブジェクトの内部インデックス テーブルと、それが参照しているユーザー テーブルをクロスチェックします。 行の不整合を検出するために、内部テーブルとユーザー テーブルの完全な積集合を実行する内部クエリが作成されます。 このクエリを実行するとパフォーマンスに多大な影響を及ぼす可能性があり、その進行状況は追跡できません。 したがって、物理的な破損とは無関係のインデックスの問題があると考えられる場合、またはページ レベルのチェックサムがオフになっており、列レベルのハードウェアの破損が考えられる場合にのみ、WITH EXTENDED_LOGICAL_CHECKS を指定することをお勧めします。
インデックスがフィルター選択されたインデックスである場合、
DBCC CHECKDBで整合性チェックを実行して、インデックス エントリがフィルター述語に適合していることを確認します。互換性レベルが 90 以下で
NOINDEXが指定されていない場合、DBCC CHECKDBを使用すると、1 つのテーブルまたはインデックス付きビューと、そのすべての非クラスター化インデックスおよび 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は、内部スナップショット データベースを作成します。この内部スナップショット データベースは、物理ファイルを使用して作成されます。 たとえば、
E:\Data\my_DB.mdf、E:\Data\my_DB.ndf、およびE:\Data\my_DB.ldfの 3 つのファイルを持つdatabase_id = 10を持つデータベースの場合、内部スナップショット データベースは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>の名前付け規則を使用して、同じフォルダー内に作成されます。 トランザクション ログのスパース ファイルは作成されません。新しいファイルは、ファイル システム レベルでスパース ファイルとマークされます。
DBCC CHECKDBコマンド中にソース データベースで更新されるデータの量に基づいて、新しいファイルで使用されるディスク上の サイズ が大きくなります。 新しいファイルの サイズ は、.mdfまたは.ndfファイルと同じファイルです。新しいファイルは、
DBCC CHECKDB処理の最後に削除されます。DBCC CHECKDBによって作成されるこれらのスパース ファイルには、"Delete on Close" 属性が設定されています。
警告
DBCC CHECKDB コマンドの実行中にオペレーティング システムで予期しないシャットダウンが発生した場合、これらのファイルはクリーンアップされません。 領域が占有され、将来の DBCC CHECKDB 実行でエラーが発生する可能性があります。 その場合は、現在実行中の DBCC CHECKDB コマンドがないことを確認した後で、これらの新しいファイルを削除できます。
新しいファイルは、エクスプローラーなどの通常のファイル ユーティリティを使用して表示できます。
Note
SQL Server 2014 (12.x) 以前では、内部スナップショット ファイルを作成するために名前付きファイル ストリームが代わりに使用されていました。 名前付きファイル ストリームでは、<filename.extension>:MSSQL_DBCC<database_id_of_snapshot> という形式が使用されています。 名前付きファイル ストリームは、Windows エクスプローラーなどの通常のファイル ユーティリティを使用して表示されません。 そのため、SQL Server 2012 (11.x) 以前のバージョンでは、ReFS形式のボリュームにあるデータベース ファイルに対して DBCC CHECKDB コマンドを実行すると、エラー メッセージ 7926 と 5030 が表示されることがあります。 これは、Resilient File System (RefS)でファイル ストリームを作成できないためです。
FILESTREAM データの確認と修復
データベースとテーブルに対して FILESTREAM が有効になっている場合、varbinary(max) バイナリ ラージ オブジェクト (BLOB) をファイル システムに格納することもできます。 BLOB をファイル システムに格納するデータベースに対して DBCC CHECKDB を使用する場合は、DBCC によって、ファイル システムとデータベースの間のリンクレベルの整合性がチェックされます。
たとえば、FILESTREAM 属性を使用する varbinary(max) 列がテーブルに含まれている場合、DBCC CHECKDB は、ファイル システム ディレクトリとファイルとテーブルの行、列、列の値の間に 1 対 1 のマッピングがあることを確認します。
DBCC CHECKDB オプションを指定すると、REPAIR_ALLOW_DATA_LOSS で破損を修復できます。 FILESTREAM の破損を修復するために、DBCC はファイル システム データが不足しているテーブル行をすべて削除します。
ベスト プラクティス
運用システムで頻繁に使用する場合は、PHYSICAL_ONLY オプションを使用することをお勧めします。
PHYSICAL_ONLY を使用すると、大規模なデータベースでの DBCC CHECKDB の実行時間を大幅に短縮できます。 また、定期的に、オプションを指定せずに DBCC CHECKDB を実行することもお勧めします。 実行する頻度は、個々の業務とその運用環境によって変わります。
Azure SQL Managed Instance では、使用可能なストレージ領域は、データによって実際に使用される量に関係なく、 DBCC CHECKDBによって作成された内部データベース スナップショット ファイル全体に対応する必要があります。 これにより、SQL マネージド インスタンスの領域が不足しているため、非常に大きくてスパースなデータベース (データのサイズがデータベース ファイル サイズよりもはるかに小さい) で DBCC CHECKDB を実行できないという状況が発生する可能性があります。 実行中 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 を使用して無効にできます。 詳細については、「トレース フラグの を参照してください。
Note
この機能は、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.
エラー報告
スタック ダンプ (SQLDump<nnnn>.txt、SQLDump<nnnn>.log、SQLDump<nnnn>.mdmp) は、破損エラーが検出されるたびに SQL Server LOG ディレクトリ DBCC CHECKDB 作成されます。
機能の使用状況データ収集とエラー報告機能が SQL Server インスタンスに対して有効になっている場合、ダンプ ファイルは自動的に Microsoft に転送されます。 収集されたデータは SQL Server の機能向上のために使用されます。
このダンプ ファイルには、DBCC CHECKDB コマンドの結果と追加の診断出力が含まれます。 アクセスが、SQL Server サービス アカウントと sysadmin ロールのメンバーに制限されます。 既定では、sysadmin ロールには、Windows の BUILTIN\Administrators グループとローカルの管理者のグループのすべてのメンバーが含まれています。 データ収集プロセスが失敗しても、DBCC コマンドは失敗しません。
エラーの解決
DBCC CHECKDBによってエラーが報告された場合は、REPAIR_* オプションのいずれかで DBCC CHECKDB を実行するのではなく、データベース バックアップからデータベースを復元することをお勧めします。 バックアップが存在しない場合は、修復を実行することによって報告されたエラーを修正します。 使用する修復オプションは、報告されたエラーの一覧の最後に指定されています。 ただし、REPAIR_ALLOW_DATA_LOSS オプションを使用してエラーを修正する場合は、一部のページ (データ) が削除されることがあります。
状況によっては、データベースに、列のデータ型に対して有効ではない値や範囲外の値が入力されていることがあります。
DBCC CHECKDB は、すべての列のデータ型について、有効ではない列の値を検出します。 したがって、以前のバージョンの SQL Server からアップグレードしたデータベースに対して、DBCC CHECKDB オプションを指定して DATA_PURITY を実行すると、以前から存在していた列の値のエラーが検出される場合があります。 SQL Server ではこれらのエラーを自動的に修復することはできないため、列の値を手動で更新する必要があります。
CHECKDB でこのようなエラーが検出されると、CHECKDB は警告 (エラー番号 2570) を返し、影響を受ける行を特定してエラーを手動で修正するための情報を示します。
ユーザー トランザクションを利用して修復を実行できるので、後からユーザーが変更をロールバックすることができます。 修復がロールバックされた場合でも、データベースにはエラーが含まれており、バックアップから復元する必要があります。 修復が完了したら、データベースをバックアップします。
データベース緊急モードでのエラーの解決
ALTER DATABASE ステートメントを使用してデータベースが緊急モードに設定されている場合、DBCC CHECKDB オプションを指定して REPAIR_ALLOW_DATA_LOSS を実行すると、データベースに対していくつかの特別な修復を実行できます。 これらの修復により、通常は回復不可能なデータベースを物理的に一貫性のある状態でオンラインに戻せる場合があります。 このような修復は、バックアップからデータベースを復元できない場合にのみ、最終的な手段として使用してください。 データベースが緊急モードに設定されている場合、データベースはREAD_ONLYとしてマークされ、ログ記録は無効になり、アクセスは固定サーバー ロール sysadmin のメンバーに制限されます。
Note
ユーザー トランザクション内で緊急モードで 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 に設定されます。 ただし、データベースに 1 つ以上のトランザクション不整合が含まれている可能性があります。
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 が自動的に実行され、物理的な整合性の問題が報告および修正されます。
論理データの一貫性とビジネス ロジックに適用される制約を手動で検証する必要があります。
トランザクション ログのサイズは既定のサイズのままであり、手動で最新のサイズに戻す必要があります。
レプリケートされたデータベースでの、REPAIR_ALLOW_DATA_LOSS を指定した DBCC CHECKDB の実行
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 固定データベース ロール sysadmin のメンバーシップが必要です。
例
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