DBCC CHECKDB によって報告されるデータベース整合性エラーのトラブルシューティング

  • [アーティクル]

この記事では、コマンドによって DBCC CHECKDB 報告されたエラーのトラブルシューティング方法について説明します。

元の製品バージョン: SQL Server
元の KB 番号: 2015748

現象

DBCC CHECKDB (または DBCC CHECKTABLE のような他の同様のコマンド) が実行されると、次のようなメッセージがSQL Serverエラー ログに書き込まれます。

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

このメッセージは、データベース整合性エラーが検出された数と、修復オプションが使用された場合に修復された数を示します。 このメッセージは、EventID=8957 の情報レベル メッセージとして Windows アプリケーション イベント ログにも書き込まれます。 エラーが報告された場合でも、このメッセージは情報レベルのメッセージです。

"内部データベース スナップショット.." で始まるメッセージ内の情報。データベースがモードになっていないSINGLE_USERオンラインで実行された場合DBCC CHECKDBにのみ表示されます。 これは、オンラインDBCC CHECKDBの場合、内部データベース スナップショットを使用して、チェックに一貫性のあるデータ セットを提示するためです。

この記事では、報告される DBCC CHECKDB 各特定のエラーのトラブルシューティング方法ではなく、エラーが報告された場合の一般的なアプローチについて説明します。 この記事の 参照CHECKDBは、説明がない限り、DBCC CHECKFILEGROUP にも適用されますDBCC CHECKTABLE。

原因

コマンドは DBCC CHECKDB 、データベース ページ、行、割り当てページ、インデックス関係、システム テーブル参照整合性、およびその他の構造チェックの物理的および論理的な整合性をチェックします。 これらのチェックのいずれかが失敗した場合 (選択したオプションに応じて)、エラーが報告されます。

これらの問題の原因は、ファイル システムの破損、基になるハードウェア システムの問題、ドライバーの問題、メモリまたはストレージ キャッシュ内の破損したページ、SQL Serverに関する問題などです。 報告されたエラーの根本原因を特定する方法については、「 根本原因の調査」を参照してください。

解決方法

  1. バックアップの復元またはデータベースの修復を続行する前に、システム上の基になるハードウェア関連の問題を解決します。 I/O パスに関連するすべてのデバイス ドライバー、ファームウェア、BIOS、オペレーティング システムの更新プログラムを適用します。 完全な I/O パス (ローカル コンピューター、デバイス ドライバー、ストレージ NIC、SAN、バックエンド ストレージ、キャッシュ) の管理者と協力して、問題を分離して解決します。 たとえば、デバイス ドライバーの更新や、I/O パス全体の構成の確認などがあります。 根本原因の確認の詳細については、「 根本原因の調査」を参照してください。

  2. 永続的な整合性エラーが報告される場合 DBCC CHECKDB は、既知の適切なバックアップからデータを復元することをお勧めします。 詳細については、「 復元と回復」を参照してください。

  3. 最新のSQL Server累積的な更新プログラムまたは Service Pack を適用して、既知の問題が発生していないことを確認します。 データベースの破損 (整合性エラー) に関連して修正された既知の問題がないか、 累積的な更新プログラムまたは Service Pack のドキュメント を確認し、関連する修正プログラムを適用します。 2017 年 2022 年 2019 年SQL Serverの詳細な修正リストがある場合は、特定のバージョンのすべての修正プログラムを検索できる 1 つの中心的な場所です。

  4. エラーが DBCC CHECKDB 断続的である場合、つまり、1 回の実行で表示され、次の実行で消える場合は、ディスク キャッシュの問題 (デバイス ドライバーまたはその他の I/O パスの問題) が発生している可能性があります。 I/O パスのメンテナと連携して、問題を分離して解決します。 たとえば、デバイス ドライバーの更新、I/O パス全体の構成の確認、I/O パスデバイスとシステム上のファームウェアと BIOS の更新などがあります。

  5. バックアップから復元できない場合は、 CHECKDB 使用できるエラーを修復する機能があります。 修復には 2 つのレベルがあります。

    • REPAIR_REBUILD - データ損失の可能性のない修復を実行します。
    • REPAIR_ALLOW_DATA_LOSS - データ損失の可能性がある修復を実行します。

    詳細については、 DBCC CHECKDB のドキュメントを参照してください。

    データベースが論理的に一貫性のない状態になる可能性があるため、データ損失を許可して修復する場合は注意が必要です。 出力は DBCC CHECKDB 、使用する最小修復レベルに関する推奨事項を作成します。 エラーが報告されなくなるまで、複数回実行CHECKDBREPAIR_ALLOW_DATA_LOSSするのが一般的な方法です。 これは、修復によって一連のエラーが修正されると、他の破損したリンケージが検出される可能性があるためです。 ただし、基になる原因が解決されていない場合は、新しいエラーが表示される可能性があります。 したがって、ハードウェアやファイル システムなどのシステム レベルの問題によってデータが破損している場合は、バックアップまたは修復の復元の前に、最初にこれらの問題に対処する必要があります。 Microsoft サポート エンジニアは、修復によって整合性エラーが修正されない場合、またはデータベースのバックアップが破損している場合、破損したデータの物理的な復旧を支援できません。

    を実行 DBCC CHECKDBすると、すべてのエラーを修復するために必要な最小修復オプションを示す推奨事項が提供されます。 これらのメッセージは次の出力のようになります。

    CHECKDB では、データベース 'mydb' で 0 個の割り当てエラーと 15 個の整合性エラーが検出されました。
    REPAIR_ALLOW_DATA_LOSS は、(mydb) によって検出された DBCC CHECKDB エラーの最小修復レベルです。

    修復の推奨事項は、 から CHECKDBのすべてのエラーを解決するための修復の最小レベルです。 最小修復レベルは、この修復オプションがすべてのエラーを修正することを意味するものではありません。 一部のエラーは修正できません。 また、修復プロセスを複数回実行する必要がある場合もあります。 報告されたすべてのエラーで、この修復レベルの使用を解決する必要はありません。 つまり、すべての修復によってCHECKDBREPAIR_ALLOW_DATA_LOSSデータが失われるわけではありません。 エラーの解決によってデータが失われるかどうかを判断するには、修復を実行する必要があります。 各テーブルの修復レベルを絞り込むのに役立つ手法の 1 つは、エラーを報告する任意のテーブルに使用 DBCC CHECKTABLE することです。 これは、特定のテーブルの修復の最小レベルを示しています。

    警告

    修復またはデータのエクスポートまたはインポートが完了した後 CHECKDB 、手動でデータ検証を実行する必要があります。 詳細については、「 DBCC CHECKDB 引数」を参照してください。 修復後、データが論理的に一貫性がない可能性があります。 たとえば、修復 (特に REPAIR_ALLOW_DATA_LOSS オプション) では、一貫性のないデータを含むデータ ページ全体が削除される場合があります。 このような場合、外部キーリレーションシップを持つテーブルが別のテーブルに存在する場合、親テーブルに対応する主キー行がない行が発生する可能性があります。

  6. データベース スキーマをスクリプト化してみてください。 スクリプトを使用して新しいデータベースを作成し、 BCP や SSIS エクスポート/インポート ウィザード などのツールを使用して、破損したデータベースから新しいデータベースにできるだけ多くのデータをエクスポートします。 破損したテーブルからのデータのエクスポートが失敗する可能性があります。 このような場合は、このテーブルをスキップし、次のテーブルに移動して、使用できる内容を保存します。

  7. によって生成される特定のエラーについては、次の記事を DBCC CHECKDB 確認し、指定された手順 (存在する場合) に従います。 次に、いくつかの例を示します:

データベース整合性エラーの根本原因を調査する

データベース整合性エラーの根本原因を特定するには、次の方法を検討してください。

  • Windows システム イベント ログで、システム レベル、ドライバー、またはディスク関連のエラーがないか確認し、ハードウェアの製造元と協力して解決してください。
  • コンピューターやディスク システムのハードウェア製造元によって提供される任意の診断を実行します。
  • ハードウェア ベンダーまたはデバイスの製造元と協力して、次のことを確認してください。
  • 整合性エラーを報告したデータベースが存在するドライブで SQLIOSim などのユーティリティを使用することを検討してください。 SQLIOSim は、ディスク システムの I/O の整合性をテストするためのSQL Server エンジンに依存しないツールです。 SQLIOSim にはSQL Serverが付属しており、別のダウンロードは必要ありません。 \MSSQL\Binn フォルダーにあります。
  • データベースの破損 (整合性エラー) に関連して修正された既知の問題がないか、 累積的な更新プログラムまたは Service Pack のドキュメント を確認し、関連する修正プログラムを適用します。 2017 年 2022 年 2019 年SQL Serverの詳細な修正リストがある場合は、特定のバージョンのすべての修正プログラムを検索できる 1 つの中心的な場所です。
  • アクセス違反やアサーションなど、SQL Serverによって報告されたその他のエラーがないか確認します。 破損したデータベースに対するアクティビティでは、アクセス違反の例外やアサート エラーが頻繁に発生します。
  • データベースで オプションが使用 PAGE_VERIFY CHECKSUM されていることを確認します。 チェックサム エラーが報告されている場合、これは、SQL Serverがディスクにページを書き込んだ後に整合性エラーが発生したことを示します。 そのため、I/O サブシステムを十分にチェックする必要があります。 チェックサム エラーの詳細については、SQL Serverのメッセージ 824 のトラブルシューティング方法に関するページを参照してください。
  • ERRORLOG でメッセージ 832 エラーを探します。 これらのエラーは、ディスクに書き込まれる前に、キャッシュに入っている間にページが破損している可能性があることを示している可能性があります。 詳細については、「SQL Serverのメッセージ 832 のトラブルシューティング方法」を参照してください。
  • 別のシステムでは、"クリーン" (エラーが発生していない) と認識されているデータベース バックアップを復元し、その後にエラーCHECKDBが生成された時間にまたがるトランザクション ログ バックアップを復元してみてください。 "クリーン" データベースのバックアップとトランザクション ログのバックアップを復元してこの問題を "再作成" できる場合は、Microsoft テクニカル サポートにお問い合わせください。
  • データの純度エラーは、アプリケーションが無効なデータをテーブルに挿入または更新するときに問題SQL Server可能性があります。 データ純度エラーのトラブルシューティングの詳細については、「SQL Server 2005 の DBCC エラー 2570 のトラブルシューティング」を参照してください。
  • chkdsk コマンドを使用して、ファイル システムの整合性を確認します。

詳細

の構文と、コマンドの DBCC CHECKDB 実行方法に関する情報またはオプションの詳細については、「 DBCC CHECKDB (Transact-SQL)」を参照してください。

を使用 CHECKDBしてエラーが見つかった場合、エラー報告のために、次のような他のメッセージが ERRORLOG に報告されます。

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

エラー情報が Watson エラー 報告に送信されました。

エラー報告に使用されるファイルには、 SQLDump<nnn>.txt ファイルが含まれます。 このファイルは、XML 形式で検出された CHECKDB エラーの一覧が含まれているので、履歴の目的で役立ちます。

データベース (最後の既知のクリーンCHECKDB) で検出されたエラーなしで最後に実行された時刻DBCC CHECKDBを調べるには、ユーザーまたはシステム データベース内の次のようなメッセージのSQL Server ERRORLOG をチェックします (このメッセージは、EventID = 17573 の Windows アプリケーション イベント ログに情報レベル メッセージとして書き込まれます)。

Date/Time spid7s データベース 'master' の CHECKDB が Date/Time22:11:11.417 (現地時刻) でエラーなしで終了しました。 これは情報メッセージのみです。ユーザーアクションは必要ありません