Microsoft SQL Serverのデータベース破損と高度な復旧テクニック徹底解説

本記事では、Microsoft® SQL Server®のデータベースレベルで発生しうる破損の種類、その検出方法、そして高度な復元および修復テクニックを用いた修正方法について詳しく解説します。

はじめに

SQL Serverは、高度な内部構造と優れた信頼性により、現在もっとも広く利用されているリレーショナルデータベース管理システム（RDBMS）のひとつです。多くの企業が重要なビジネスデータの保存・管理のためにSQL Serverデータベースを採用しています。

企業はデータベース管理者（DBA）に対して、データベースのパフォーマンス、メンテナンス、セキュリティの継続的な向上を期待しています。しかし、データベースが破損してデータにアクセスできなくなった場合、その原因はハードウェア障害、ディスクの問題、ウイルス攻撃、オペレーティングシステム（OS）の障害など多岐にわたる可能性があります。最適な手法を知らなければ、破損したデータベースの修復は決して容易な作業ではありません。

この記事では、データベース破損の主な原因を取り上げ、ページ破損の特定方法を説明し、DBCC CHECKDBコマンドの詳細を掘り下げたうえで、高度な復元・修復テクニックを実演します。

データベース破損とは

SQL Serverはユーザーデータを「ページ」という単位で保存します。これらのページは.MDF（プライマリ）データファイル内に格納されています。.MDFファイルが破損すると、データベース全体が破損する恐れがあります。データファイルのページは、SQL Serverのメモリからディスクへ書き出される時点では正常ですが、メモリに読み戻す際に破損していることがあります。以下のイメージをご覧ください。

データベース破損の原因

データベース破損の種類には、以下のようなものがあります。

• I/Oサブシステム（データベース破損のもっとも一般的な原因のひとつ）
• Windowsオペレーティングシステム
• 暗号化やアンチウイルスなどのファイルシステムドライバー
• SANまたはRAIDコントローラー
• ディスク
• メモリ
• ファイルヘッダー
• SQL Server自体のバグ
• 人的ミス

エラーメッセージ

破損したデータベースにアクセスすると、以下のようなエラーメッセージが表示されることがあります。

• SQL ServerのMsg 823
• SQL ServerのMsg 824
• SQL ServerのMsg 825（読み取り再試行）
• SQL Serverエラー9004
• メタデータ破損エラー
• ページレベル破損エラー

ページ破損の検出

SQL Serverには、ディスクへのページの読み書きなどI/O操作中に破損が発生した際に、自動的にそれを識別して警告する組み込みメカニズムが備わっています。

SQL Serverでは、ディスク上のページを保護するために、以下の2種類のページレベル検証オプションが利用可能です。

• TORN_PAGE_DETECTION
• チェックサム（Checksum）

TORN_PAGE_DETECTIONを指定した場合、8KBのデータファイルページがディスクに書き込まれるたびに、16個×512バイトのディスクセクタごとにビットが反転されます。その後ページがメモリに読み込まれる際にこれらの値が比較され、ビットが誤った状態で見つかれば、ページが正しく書き込まれなかった可能性があります。この場合、システムは torn-page エラーを示すエラーメッセージ824を生成します。

チェックサムを指定した場合、ページをディスクに書き込む際にページ内容全体からチェックサム値が計算され、その値がページヘッダーに格納されます。後でページがディスクから読み込まれると、チェックサムが再計算され、ページヘッダーに格納された値と比較されます。値が一致しない場合、システムはチェックサム失敗を示すエラーメッセージ824を生成します。

823（ハードI/Oエラー）と824（ソフトI/Oエラー）はどちらも重大度24のエラーであり、msdb.dbo.suspect_pagesテーブルに記録されます。

msdb.dbo.suspect_pagesテーブルは単一ページの復元操作に使用され、SQL ServerエラーログやWindows®イベントログにも記録できます。

DBCC CHECKDB

DBCC CHECKDBは、データベース内のすべてのオブジェクトの物理的および論理的な整合性をチェックします。

これはリソースを大量に消費する操作であり、並列処理を使用しますが、トレースフラグ2528を使用することでシングルスレッドで実行することも可能です。

重要なシステムテーブルに対するプリミティブチェック

プリミティブチェックは、ストレージエンジンのメタデータを保持する重要なシステムテーブルと、MDFファイル内にデータが格納されているアロケーションパスに対して実行されるように設計されています。

プリミティブチェックには以下が含まれます。

• DBCC CHECKALLOC：データベース内のアロケーション構造の一貫性をチェックします。アロケーション構造が有効であること、および単一のデータファイルページが2つのテーブルに割り当てられていないことを確認します。

• DBCC CHECKTABLE：テーブルとインデックスの一貫性をチェックします。テーブルおよび関連するインデックスの構造を検証し、インデックスデータがテーブル内の行と一致しているかどうかを判定し、インデックスの順序キーを調べます。テーブルでFILESTREAMが使用されている場合は、リンクの存在も検証します。

• DBCC CHECKCATALOG：システムカタログ間の一貫性をチェックします。

• DBCC CHECKFILEGROUP：DBCC CHECKDBと同様に、ファイルグループに対する一貫性チェックとデータベースに対するアロケーションチェックを実行します。

サンプルコード

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 ]
    }
  ]
]

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

CHECKDBで内部データベーススナップショットを使用してチェックを実行し、トランザクションの一貫性を維持することで、ブロッキングや同時実行の問題を防ぐことができます。データベーススナップショットを作成できない場合は、テーブルレベルのチェックを実行するために必要となるため、データベースの排他ロックと共有テーブルロックがあることを確認してください。スナップショットが作成されていない場合、CHECKDBはmasterデータベース上で失敗します。

以下は、DBCC CHECKDBが実行する内部チェックの一覧です。

• 重要なシステムテーブルのチェック
• 重要なシステムテーブルの論理チェック
• その他のテーブルの論理チェック
• アロケーションチェック
• メタデータチェック
• Service Broker検証チェック
• インデックス付きビュー、空間インデックスのチェック

CHECKDBのエラー

次の表は、DBCC CHECKDBの代表的なエラーを示しています。

ベストプラクティス

大規模データベース（VLDB）でCHECKDBの実行時間に問題がある場合は、PHYSICAL_ONLYオプションを頻繁に使用して、VLDB本番データベースの実行時間を短縮することを推奨します。ただし、通常はオプションを指定せずにDBCC CHECKDBを実行することが望ましいでしょう。CHECKDBの実行スケジュールは、個々の本番環境に応じて設定してください。

高度な復元オプション

破損問題に対してはシンプルなデータベース復元手法を使う人がほとんどですが、以下のような高度な復元テクニックも利用可能です。

ページ復元

このテクニックでは、1つ以上のページを復元できます。ページレベル復元はEnterprise Editionのデータベースではオンライン操作として実行でき、その他のエディションではオフライン操作として使用できます。つまり、復元プロセス中にデータベースをオフラインにすることが可能です。

T-SQLスクリプト

RESTORE DATABASE <database_name>
PAGE = '<file: page> [ ,... n ] ' [ ,... n ]
FROM <backup_device> [ ,... n ]
WITH NORECOVERY

ページIDを取得するには、エラーログ、イベントトレース、DBCC、破損ページとそのIDを一覧表示するmsdb..suspect_pagesテーブルのレコードなど、さまざまなソースを利用できます。

注意：ブートページ、ファイルヘッダーページ、重要なシステムテーブルの一部のページ、アロケーションビットマップは、ページ復元の対象にできません。

段階的復元と部分復元

ページ復元と同様に、複数のファイルまたはファイルグループを含むデータベースに対して、Enterprise Editionではオンラインで、その他のエディションではオフラインで、段階的（piecemeal）復元と部分（partial）復元を実行できます。

すべての段階的復元は、PARTIALオプションを付けてフルバックアップを復元するRESTORE DATABASEステートメントによる部分復元シーケンスから始まります。この復元が完了すると、データベースは部分的にオンラインになります。つまり、残りのファイルは復旧が延期されているため、「復旧保留中」モードになります。

段階的復元は、データベースの復旧モデルとその復旧シーケンスに依存します。

復元シーケンス

ファイルグループXとZ、およびプライマリファイルグループの部分復元を実行するには、以下のコードを実行します。

RESTORE DATABASE DB_XYZ FILEGROUP='X',FILEGROUP='Z'
  FROM partial_backup
  WITH PARTIAL, RECOVERY;

上記の時点Xでは、以下の状態になっています。

• ファイルグループZとプライマリファイルグループはオンライン。
• ファイルグループY内のファイルは復旧保留中。
• ファイルグループはオフライン。

次に、RESTORE DATABASE DB_XYZ FILEGROUP='Y' FROM backup WITH RECOVERY;を実行します。

これですべてのファイルグループがオンラインになります。

その他の高度な修復テクニック

修復は常にデータ復旧を保証するのでしょうか？答えは「ノー」です。

データを破損させる可能性のある組み合わせは数多く存在し、すべての組み合わせをテストすることは不可能です。たとえば、システムテーブルが破損した場合、BootページやPFSページなどのページに対しては修復が機能しません。

以下に、いくつかの修復オプションを紹介します。

REPAIR_REBUILD

このオプションは修復を実行しますが、破損した非クラスタ化（NC）インデックスを再構築する際にデータ損失が発生する可能性があります。

REPAIR_ALLOW_DATA_LOSS

このオプションは修復を実行しますが、データ損失が発生する可能性があります。

システムテーブルインデックスの再構築

クラスタ化されたシステムテーブルインデックスは修復できませんが、状況によっては、DBCC CHECKTABLEオプションを確認することで非クラスタ化インデックスを修復できる場合があります。

注意：深刻な事態を避けるため、高度な修復テクニックは必ず元のデータベースではなくコピーしたデータベースに対して実行してください。

非クラスタ化インデックスからのデータ再構築

クラスタ化インデックスまたはヒープが破損している場合、非クラスタ化（NC）インデックスからデータを復旧する唯一の選択肢は修復です。ただし、メタデータが破損している場合は、修復が機能しないこともあります。

SELECTステートメントを使用して、破損していないNCインデックスの選択を強制できますが、これはNCインデックスのカラムレベルのカバレッジに依存する場合があります。

DBCC PAGE

DBCC PAGE … WITH TABLERESULTSを使用すると、キー範囲を特定できます。非クラスタ化インデックスからキー範囲を構築し、破損したページを調査することで、ページからデータを取得できる可能性があります。

まとめ

この記事を読めば、データベース破損の仕組みと、シンプルな手法と高度な手法の両方を使ったデータベース復旧方法について、より深く理解できたはずです。さらに、これらのテクニックは破損後にデータベースをオンラインに戻す際にも役立ちます。破損によるダウンタイムを回避するためには、常に堅牢なバックアップ計画を立てておくことが重要です。

コメントやご質問がある場合は、フィードバックタブをご利用ください。

専門家による管理・運用・構成で環境を最適化

Rackspaceのアプリケーションサービス（RAS）のエキスパートは、幅広いアプリケーションポートフォリオにわたって、以下のプロフェッショナルサービスおよびマネージドサービスを提供しています。

• eコマースおよびデジタルエクスペリエンスプラットフォーム
• エンタープライズリソースプランニング（ERP）
• ビジネスインテリジェンス
• Salesforce顧客関係管理（CRM）
• データベース
• メールホスティングおよび生産性向上ツール

私たちが提供するもの：

• 偏りのない専門知識：即座に価値をもたらす機能に焦点を当て、お客様のモダナイゼーションの旅をシンプルにし、導きします。
• Fanatical Experience™：「Process first. Technology second.®」のアプローチと専任のテクニカルサポートを組み合わせ、包括的なソリューションを提供します。
• 比類のないポートフォリオ：豊富なクラウド経験を活かし、適切なクラウド上に適切なテクノロジーを選択・導入できるよう支援します。
• アジャイルなデリバリー：お客様の旅のどの段階においてもお客様とともに歩み、私たちの成功をお客様の成功と一致させます。

今すぐチャットでご相談ください。