データ破損からの復旧

データ破損 (ブロック/ページのチェックサムエラー、読み取り不能なテーブル、破損した RDB/AOF) に対する段階的な診断フロー: まず破損範囲を確認し、ブロックレベルのリカバリ、バックアップからの完全リストア/PITR、最終手段の修復ツールのいずれかを正しく選択する。

破損範囲はどの程度か?

まず整合性チェックを実行し、破損がどこまで広がっているかを判断する。破損しているのは少数のブロック/ページのみか、単一オブジェクト (テーブル/インデックス) が影響を受けているか、それとも破損が広範囲か? 以下のコマンドでスキャンして範囲を判断し、該当する分岐を選択する。

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;  -- then: SELECT file#, block#, blocks, corruption_type FROM v$database_block_corruption;

• 少数のブロック / ページのみ破損
• 単一オブジェクト (テーブル/インデックス) が影響を受けている
• 破損が広範囲 / 多数のオブジェクト
• チェックツールが動作せず、DB がオープンできない
• 破損が繰り返し発生する (根本原因が疑われる)

根本原因: 限定的なブロック/ページ破損 → 対象を絞ったリカバリ

破損しているのが少数のブロック/ページのみであれば、データベース全体をリストアする必要はない。エンジンのブロック/ページレベルのリカバリ機能を使い、破損部分のみをバックアップ/ログから修復してデータ損失を最小化する。

根本原因: オブジェクトレベル/広範囲の破損 → バックアップからの完全リストアまたは PITR

破損が 1 つ以上のオブジェクトに広がっている場合、最も安全なのは正常なバックアップからリストアし、可能であれば破損発生時点までロールフォワード (PITR) すること。これにより修復ツールが引き起こすデータ損失を回避できる。

バックアップなし / DB がオープンできない — 最終手段に進むか?

修復ツール (REPAIR_ALLOW_DATA_LOSS、innodb_force_recovery、--fix) はデータ損失を引き起こす可能性があり、整合性制約を破壊する場合がある。使用可能なバックアップが存在せず、データベースをオープンできない場合に限る最終手段。まず使用可能なバックアップが本当にないことを確認する。

• 正常なバックアップが見つかったのでリストアする
• バックアップがまったくなく、修復ツールしか選択肢がない

最終手段: データ損失リスクのある修復ツール

これらのツールは、破損した行/ページを破棄してデータベースをオープン可能にする。バックアップがなく、既存ファイルのコピーを先に取得した場合にのみ使用する。目的: データをエクスポートできる程度にオープンし、クリーンなコピーへ移行すること。

根本原因: ハードウェア/インフラ → 発生源を修正し、チェックサムを有効化する

破損が繰り返し発生する場合、真の原因はディスク、コントローラー、メモリ (RAM)、または不安定なストレージ層である可能性が高い。データをリカバリするだけでは不十分で、発生源を修正しなければ破損は再発する。早期検出のためにチェックサム/整合性検証も有効化する。