次の方法で共有

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

  • [アーティクル]

この記事では、 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 アプリケーション イベント ログにも書き込まれます。 エラーが報告された場合でも、このメッセージは情報レベルのメッセージです。

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

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

原因

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

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

解決方法

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

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

  3. 最新の SQL Server 累積的な更新プログラムまたは Service Pack を適用して、既知の問題が発生していないことを確認します。 データベースの破損 (整合性エラー) に関連して修正された既知の問題については更新プログラムまたは Service Pack のドキュメントを確認し、関連する修正プログラムを適用します。 SQL Server 2022、2019、2017 の Detailed 修正リストがある場合は、特定のバージョンのすべての修正プログラムを検索できる 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出力では、使用する最小修復レベルに関する推奨事項が作成されます。 CHECKDBは、エラーが報告されない限り、REPAIR_ALLOW_DATA_LOSS複数回実行するのが一般的です。 これは、修復によって一連のエラーが修正されると、他の破損したリンケージが発見される可能性があるためです。 ただし、基になる原因が解決されていない場合は、新しいエラーが表示される可能性があります。 そのため、ハードウェアやファイル システムなどのシステム レベルの問題が原因でデータが破損している場合は、バックアップまたは修復を復元する前に、まずこれらの問題に対処する必要があります。 Microsoft サポート エンジニアは、修復によって整合性エラーが修正されない場合、またはデータベースのバックアップが破損している場合、破損したデータの物理的な回復を支援できません。

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

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

    修復の推奨事項は、 CHECKDBからすべてのエラーを解決するための最小レベルの修復です。 最小修復レベルは、この修復オプションがすべてのエラーを修正することを意味するわけではありません。 一部のエラーは単に修正できません。 また、修復プロセスを複数回実行する必要がある場合もあります。 報告されたすべてのエラーで、この修復レベルの使用を解決する必要があるわけではありません。 つまり、REPAIR_ALLOW_DATA_LOSSCHECKDBによるすべての修復によってデータが失われるわけではありません。 エラーの解決によってデータが失われるかどうかを判断するには、修復を実行する必要があります。 各テーブルの修復レベルを絞り込むのに役立つ 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 のドキュメントを確認し、関連する修正プログラムを適用します。 SQL Server 2022、2019、2017 の Detailed 修正リストがある場合は、特定のバージョンのすべての修正プログラムを検索できる 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 コマンドを使用して、ファイル システムの整合性を確認します。 SQL Server の実行中chkdskを実行しないでください。 SQL Server がチェック対象のファイルに書き込む場合、一時的なファイル エラーが報告される可能性があります。 また、 /r や /f などのスイッチは、ファイル バイトをディスク上の別の場所に移動する可能性があり、SQL Server がこれらのファイルに対して書き込みや読み取りを行うと、このような移動が破損する可能性があります。 そのため、 chkdsk コマンドを実行する前に、必ず SQL Server を停止してください。 また、 /r や /fなどの修復オプションには注意してください。 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 から検出されたエラーの一覧が含まれているので、履歴の目的で役立ちます。

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

Date/Time spid7s CHECKDB for database 'master' finished without errors on Date/Time22:11:11.417 (現地時刻)。 これは情報メッセージのみです。ユーザー操作は必要ありません