データ破損

症状

'ORA-01578'、'page corruption'、'checksum mismatch'、'MISCONF'、読み取り時の I/O 一貫性エラー。

1. 冷静さを保ち、拡大を止める

慌てた介入は事態を悪化させる。まず範囲を特定し、可能なら影響を受けたオブジェクトへの書き込みを停止する。ハードウェア関連 (ディスク/コントローラー) であれば OS/ハードウェアのログも確認する — DB を直してもディスクは直らない。

2. 範囲を特定する: どれだけ破損しているか

単一のブロック/ページ/オブジェクトか、広範囲か。整合性チェックを実行する。

Oracle

RMAN> VALIDATE DATABASE;  -- or: SELECT * FROM v$database_block_corruption;

PostgreSQL

-- With data_checksums enabled it shows up in the logs; check indexes/heap with pg_amcheck:
-- pg_amcheck --heapallindexed -d mydb

MySQL

CHECK TABLE customer;  -- for InnoDB, innodb_force_recovery is the last resort

SQL Server

DBCC CHECKDB ('MyDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Redis

redis-check-rdb dump.rdb
# AOF (Redis 7+ multi-part: under appendonlydir/, pass the manifest file):
redis-check-aof appendonlydir/appendonly.aof.manifest
# --fix TRUNCATES everything after the corrupted point (writes in that part are lost); back up the directory first:
# redis-check-aof --fix appendonlydir/appendonly.aof.manifest

3. 優先事項: バックアップからの復旧

破損時の最も安全な方法は、正常なバックアップからのリストアである。ブロック/ページレベルの復旧がサポートされていれば、破損部分のみを復旧する (Oracle RMAN BLOCKRECOVER、MSSQL ページリストア)。修復ツール (DBCC REPAIR_ALLOW_DATA_LOSS、innodb_force_recovery) はデータ損失を引き起こす — 最後の手段である。

4. 整合性を検証する

復旧後、チェック (DBCC CHECKDB / RMAN VALIDATE / CHECK TABLE) を再実行し、クリーンな結果になることを確認する。アプリケーション側でもデータの整合性 (行数、重要な合計値) を検証する。

5. 根本原因: 通常はハードウェア

破損は通常、ディスク/メモリ/コントローラーの障害に起因する。ハードウェアをテスト/交換し、チェックサムを有効にし (data_checksums、PAGE_VERIFY CHECKSUM)、バックアップと検証の運用を強化する。DBCC CHECKDB / RMAN VALIDATE を定期的にスケジュールする。