【完全ガイド】ORA-01578: ORACLE data block corrupted の原因と解決方法｜RMAN BLOCKRECOVER・DBVERIFY・Data Guard 徹底解説

Oracle DBA が本番で最も対応を迫られる致命的エラー:

SELECT COUNT(*) FROM my_table;
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 1027)
ORA-01110: data file 4: '/u03/oradata/orcl/users01.dbf'

「Oracle データブロックが破損」というシンプルなメッセージ。しかし、これはデータ整合性の重大な障害を意味します:

• 特定ブロックのデータ読み取り不能
• クエリ実行中の突然の失敗
• 業務データの潜在的損失リスク
• 緊急バックアップ確認必須
• DBA の即時対応が必要

このエラーの本質は、Oracle がデータブロックの整合性チェックに失敗:

1. データファイル内の特定ブロック（8KB 等）を読み取り
2. ブロックヘッダー / チェックサム検証
3. 破損検出 → ORA-01578

必ず併発する ORA-01110 で破損位置が判明:

ORA-01578: ORACLE data block corrupted (file # X, block # Y)  ← 破損通知
ORA-01110: data file X: '/path/to/datafile.dbf'                ← ファイル位置

物理破損 vs 論理破損

極めて重要な区別:

物理破損 (Physical Corruption):
- ハードウェア障害（ディスク、メモリ）
- I/O エラー、電源断
- ストレージ故障
- チェックサム不一致

論理破損 (Logical Corruption):
- Oracle 内部データ構造の不整合
- インデックスとテーブルの不一致
- ROW チェーン異常
- Oracle バグ

対処方法が全く異なるため、まず判別が必要です。

現場で発生する典型パターン:

• ディスクの物理故障（Head Crash, Bad Sector）
• RAID コントローラの障害
• SAN / NASのネットワーク障害
• **メモリ (RAM)**のビット反転
• 電源断による書き込み中の中断
• ファイルシステムの破損（ext4/xfs）
• NFSの一時的な障害
• Oracle ソフトウェアバグ
• 管理者の不正操作（データファイル手動編集）
• OS カーネルバグ

多くの日本語記事が「RMAN で修復せよ」で終わりますが、実務では:

• 物理破損と論理破損の判別が最優先
• DBVERIFY によるオフラインでの精査
• V$DATABASE_BLOCK_CORRUPTION ビューの活用
• RMAN VALIDATE による全体スキャン
• BLOCKRECOVER のEnterprise Edition 限定性
• DBMS_REPAIR による破損ブロックのスキップ
• Event 10231 による一時回避
• Data Guard スタンバイから自動修復
• CTAS による救出可能データの抽出
• バックアップなしでの復旧戦略

さらに、Oracle Active Data Guard 環境では画期的な自動修復機能:

プライマリで ORA-01578 検出
   ↓
Active Data Guard スタンバイから健全なブロックを自動取得
   ↓
バックグラウンドで修復
   ↓
アプリは中断なし

24時間運用における最強の防御策です。

本記事では、ORA-01578: ORACLE data block corrupted の完全な原因と解決方法を、リファレンスとして実用的に整理します。10大発生パターン、物理/論理破損の判別、6つの解決策、DBVERIFY / RMAN / DBMS_REPAIR、Rails/Java/Python 対応、実践シナリオ、FAQまで完全網羅。この1本で ORA-01578 に冷静に的確に対処できるようになります。

結論：バックアップの確認と RMAN 修復

時間がない方向けに、最速の対処を先に示します。

エラーメッセージの読み方

ORA-01578: ORACLE data block corrupted (file # X, block # Y)
                                             ↑         ↑
                                        ファイル番号  ブロック番号
ORA-01110: data file X: '/path/to/file.dbf'
                    ↑
              破損ファイルの物理パス

最速の緊急対応

# STEP 1: 全体スキャン
sqlplus / as sysdba
SQL> SELECT * FROM v$database_block_corruption;

# STEP 2: RMAN で詳細確認
rman target /
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

# STEP 3: 破損したブロックの所属確認
SQL> SELECT owner, segment_name, segment_type 
     FROM dba_extents 
     WHERE file_id = X AND Y BETWEEN block_id AND block_id + blocks - 1;

# STEP 4: RMAN で修復
RMAN> BLOCKRECOVER DATAFILE X BLOCK Y;

# または全ての破損ブロック
RMAN> BLOCKRECOVER CORRUPTION LIST;

6つの解決策

物理破損 vs 論理破損の判別

-- 破損タイプ確認
SELECT file#, block#, corruption_type, corruption_change#
FROM v$database_block_corruption;

-- CORRUPT: 物理破損
-- FRACTURED: 分断（物理）
-- CHECKSUM: チェックサム不一致（物理）
-- LOGICAL: 論理破損
-- ALL ZERO: 全ゼロ（物理）

詳細は以下で解説します。

Oracle データブロックの仕組み

データブロック構造

Oracle データブロック (8KB デフォルト):
+------------------+
| ブロックヘッダー     |  <- チェックサム、SCN 等
+------------------+
| テーブル管理領域    |
+------------------+
| ROW ディレクトリ    |
+------------------+
| ROW データ         |
+------------------+
| 空き領域           |
+------------------+

整合性チェック

Oracle が読み取り時にチェック:

1. ブロックヘッダー検証
2. チェックサム計算 vs 保存値比較
3. ROW ディレクトリ整合性
4. データ構造整合性

失敗時 → ORA-01578。

DB_BLOCK_CHECKSUM パラメータ

SHOW PARAMETER db_block_checksum;
-- TYPICAL (デフォルト): 書き込み時にチェックサム
-- FULL: 読み書き両方でチェックサム
-- OFF: チェックサムなし（非推奨）

本番は TYPICAL 以上推奨。

【原因①】ハードウェア故障（最頻出）

症状

alert log:

ORA-01578: ORACLE data block corrupted (file # 6, block # 881945)
ORA-01110: data file 6: '/u01/app/oracle/data/DEVQA/datafile/mgmt.dbf'

DBV-00200: Block, DBA 25936658, already marked corrupt
csc(0x0000.2e078166) higher than block scn(0x0000.00000000)

診断

A. OS ログ確認:

dmesg | grep -E "(I/O error|read error|drive)"
tail -100 /var/log/messages | grep -E "(sda|sdb|nvme)"

B. スマート情報:

smartctl -a /dev/sda
# Reallocated_Sector_Ct, Current_Pending_Sector 等

C. RAID コントローラ:

# LSI (Broadcom)
storcli /c0 show
# Dell PERC
perccli /c0 show

# HPE
ssacli ctrl all show config

解決

A. ハードウェア修理（根本対処）:

• 故障ディスク交換
• RAID 再構築
• コントローラ交換

B. RMAN で修復（データ復旧）:

rman target /
RMAN> BLOCKRECOVER DATAFILE 6 BLOCK 881945;

【原因②】ストレージ / SAN 障害

症状

SAN パス障害、ファブリック障害:

alert log:
"IO Error: Software caused connection abort"
"ORA-27070: async read/write failed"
"ORA-01578: ORACLE data block corrupted"

診断

# マルチパス確認
multipath -ll

# SAN パス
systool -c fc_host -v

# HBA 状態
cat /sys/class/fc_host/host*/port_state

解決

A. パス復旧、ケーブル交換、ファブリック管理。 B. 修復後 RMAN VALIDATE + BLOCKRECOVER。

【原因③】I/O エラー（電源断）

シナリオ

1. 大量書き込み中
2. 突然の電源断（UPS 失敗）
3. 書き込み途中のブロック
4. 部分書き込み（Fractured block）
5. ORA-01578 (FRACTURED)

対処

A. UPS / DR 対策強化。 B. RMAN BLOCKRECOVER で修復:

RMAN> BLOCKRECOVER CORRUPTION LIST;

【原因④】メモリ (RAM) 障害

症状

キャッシュ内でビット反転:

alert log:
"ORA-00600: internal error, arguments [kcbz_bha]"
"ORA-01578: ORACLE data block corrupted"

診断

# メモリテスト
memtester 4G 3

# または起動時
# GRUB → memtest86+ 実行

解決

A. ECC メモリ搭載推奨。 B. 不良 DIMM 交換。 C. Oracle 内では _disable_incremental_checkpoints=FALSE 等の設定確認。

内部エラーは ORA-00600: internal error の記事も参照してください。

【原因⑤】NFS / NAS 障害

シナリオ

データファイルが NFS 上
→ ネットワーク瞬断
→ 部分書き込み
→ ORA-01578

対処

A. ローカルディスク推奨（NFS は避ける）。 B. どうしても NFS なら NFSv4 + hard,intr マウント:

/etc/fstab:
nas:/export /oradata nfs hard,intr,rsize=32768,wsize=32768 0 0

【原因⑥】ファイルシステム破損

シナリオ

ext4 / xfs のインデックス破損
→ ブロックマッピング不整合
→ ORA-01578

診断

# xfs
xfs_repair -n /dev/sda1   # 読み取り専用チェック

# ext4
fsck.ext4 -n /dev/sda1

解決

A. ファイルシステム修復（アンマウント必要）。 B. RMAN で復旧。

【原因⑦】Oracle ソフトウェアバグ

症状

特定パッチレベルで既知バグ
alert log に ORA-00600 と併発

診断

MOS (My Oracle Support) で検索:

• Doc ID: XXXXXXX
• パッチ情報

解決

A. パッチ適用。 B. Workaround 実施。

【原因⑧】不正なファイル操作

シナリオ

- 管理者が誤ってデータファイルを cp / mv 中に破損
- バックアップから不正なファイル復元
- OS 直接編集

対処

A. 手順書遵守、OS 直接操作禁止。 B. RMAN で正しい手順:

RMAN> RESTORE DATAFILE 6;
RMAN> RECOVER DATAFILE 6;

【原因⑨】OS カーネルバグ

シナリオ

特定 Linux カーネルで
DIRECTIO 不整合
→ ORA-01578

対処

A. カーネルアップグレード。 B. FILESYSTEMIO_OPTIONS 変更:

ALTER SYSTEM SET filesystemio_options = SETALL SCOPE=SPFILE;
-- 再起動必要

【原因⑩】RAID 障害

シナリオ

RAID5 で複数ディスク故障
→ パリティ再計算失敗
→ データブロック不整合
→ ORA-01578

対処

A. RAID10 推奨（パフォーマンス + 冗長性）。 B. RAID 再構築中はスナップショット確保。

診断ツール完全リファレンス

V$DATABASE_BLOCK_CORRUPTION

SELECT file#, block#, blocks, corruption_change#, corruption_type
FROM v$database_block_corruption;

-- CORRUPTION_TYPE:
-- CORRUPT: 物理破損
-- FRACTURED: 分断書き込み
-- CHECKSUM: チェックサム不一致
-- LOGICAL: 論理破損
-- ALL ZERO: 全ゼロ（物理）
-- NOLOGGING: NOLOGGING 操作後

DBVERIFY (dbv)

オフラインでの精査:

dbv file=/u01/oradata/PROD/users01.dbf blocksize=8192

# 特定ブロック範囲
dbv file=/u01/oradata/PROD/users01.dbf start=23400 end=23500

# 出力例
DBVERIFY - Verification complete
Total Pages Examined         : 51200
Total Pages Processed (Data) : 48234
Total Pages Failing   (Data) : 3        <-- 破損検出!
Total Pages Marked Corrupt   : 3

RMAN VALIDATE

rman target /

# 全 DB 論理チェック
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

# 特定表領域
RMAN> BACKUP VALIDATE CHECK LOGICAL TABLESPACE users;

# 特定データファイル
RMAN> BACKUP VALIDATE DATAFILE 4;

# 並列で高速化
RMAN> RUN {
  ALLOCATE CHANNEL c1 TYPE DISK;
  ALLOCATE CHANNEL c2 TYPE DISK;
  ALLOCATE CHANNEL c3 TYPE DISK;
  ALLOCATE CHANNEL c4 TYPE DISK;
  BACKUP VALIDATE CHECK LOGICAL DATABASE;
}

影響オブジェクト特定

SELECT owner, segment_name, segment_type, tablespace_name
FROM dba_extents
WHERE file_id = 4 
  AND 1027 BETWEEN block_id AND block_id + blocks - 1;

alert log

tail -200 /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log

# エラー抽出
grep -B 2 -A 5 "ORA-01578" alert_orcl.log

6つの解決策 完全リファレンス

解決策① RMAN BLOCKRECOVER

Enterprise Edition のみ:

rman target /

# 特定ブロック
RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 1027;

# 複数ブロック
RMAN> BLOCKRECOVER DATAFILE 5 BLOCK 30123, 30124, 30125;

# 全破損ブロック
RMAN> BLOCKRECOVER CORRUPTION LIST;

# バックアップから
RMAN> RUN {
  ALLOCATE CHANNEL c1 TYPE 'DISK';
  BLOCKRECOVER DATAFILE 92 BLOCK 20737;
  RELEASE CHANNEL c1;
}

解決策② データファイル RESTORE

広範囲の破損:

rman target /

# データファイルオフライン
RMAN> ALTER DATABASE DATAFILE 4 OFFLINE;

# RESTORE
RMAN> RESTORE DATAFILE 4;

# RECOVER
RMAN> RECOVER DATAFILE 4;

# オンライン
RMAN> ALTER DATABASE DATAFILE 4 ONLINE;

解決策③ Data Guard から自動修復

Active Data Guard ライセンス必要:

-- 自動修復（Real-Time Query スタンバイあり）
-- プライマリが自動的にスタンバイから健全なブロック取得
-- バックグラウンドで実行
-- アプリ中断なし

解決策④ DBMS_REPAIR

バックアップなし、データ諦め可:

-- 破損ブロックをスキップ設定
BEGIN
  DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(
    schema_name => 'SCOTT',
    object_name => 'EMP',
    flags => DBMS_REPAIR.SKIP_FLAG
  );
END;
/

-- 以降のクエリは破損ブロックをスキップ
SELECT * FROM scott.emp;

⚠️ データ損失を伴う、慎重に判断。

解決策⑤ Event 10231 スキップ

-- セッションレベル（一時的）
ALTER SESSION SET EVENTS '10231 trace name context forever, level 10';

-- システムレベル
ALTER SYSTEM SET EVENTS '10231 trace name context forever, level 10';

-- 以降のフル テーブル スキャンは破損ブロックスキップ
SELECT * FROM scott.emp;

解決策⑥ CTAS でデータ救出

-- 健全な部分だけコピー
CREATE TABLE emp_backup AS 
SELECT * FROM emp
WHERE ROWID NOT IN (
  SELECT DBMS_ROWID.ROWID_CREATE(...)
  FROM v$database_block_corruption
  WHERE ...
);

Rails / Java / Python 対応

アプリからの検出

ORA-01578 発生時:

• 既存の接続: 該当クエリで即座失敗
• 新規接続: 別クエリなら可能
• 緊急対応が最優先、アプリ側は監視

Rails ActiveRecord

begin
  User.all.each { |u| process(u) }
rescue ActiveRecord::StatementInvalid => e
  if e.message.include?("ORA-01578")
    Rails.logger.fatal "ORA-01578: DATA BLOCK CORRUPTION"
    # 即座に DBA へ通知
    NotifyOps.critical("Oracle block corruption: #{e.message}")
    # 影響範囲を切り分け
    raise
  end
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事も参照してください。

Java (JDBC)

try {
    ResultSet rs = ps.executeQuery();
    while (rs.next()) {
        // 処理
    }
} catch (SQLException e) {
    if (e.getErrorCode() == 1578) {
        logger.fatal("ORA-01578: Block corruption detected: " + e.getMessage());
        alertingService.critical("Oracle data integrity issue");
    }
}

Python (oracledb)

import oracledb
import logging

try:
    cursor.execute("SELECT * FROM my_table")
    for row in cursor:
        process(row)
except oracledb.DatabaseError as e:
    error_obj, = e.args
    if error_obj.code == 1578:
        logging.critical(f"Block corruption: {error_obj.message}")
        # DBA へ通知

実践シナリオ

シナリオ1：本番緊急対応

# 1. アラート受信
# "ORA-01578: ORACLE data block corrupted"

# 2. サーバー接続
ssh dbserver

# 3. 現状確認
sqlplus / as sysdba

SQL> SELECT * FROM v$database_block_corruption;
SQL> SELECT file#, name FROM v$datafile WHERE file# = 4;

# 4. 影響オブジェクト特定
SQL> SELECT owner, segment_name, segment_type
     FROM dba_extents
     WHERE file_id = 4 
       AND 1027 BETWEEN block_id AND block_id + blocks - 1;

# 5. バックアップ状態確認
rman target /
RMAN> LIST BACKUP OF DATABASE;
RMAN> LIST BACKUP OF DATAFILE 4;

# 6. 修復（バックアップあり）
RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 1027;

# 7. 確認
sqlplus / as sysdba
SQL> SELECT COUNT(*) FROM affected_table;
-- 成功なら修復完了

シナリオ2：全体スキャンでの検出

# 定期的な健全性チェック
rman target /

RMAN> RUN {
  ALLOCATE CHANNEL c1 TYPE DISK;
  ALLOCATE CHANNEL c2 TYPE DISK;
  ALLOCATE CHANNEL c3 TYPE DISK;
  ALLOCATE CHANNEL c4 TYPE DISK;
  BACKUP VALIDATE CHECK LOGICAL DATABASE;
}

# 結果確認
sqlplus / as sysdba
SQL> SELECT * FROM v$database_block_corruption;

シナリオ3：DBVERIFY でオフライン検査

# 全データファイル対象スクリプト
#!/bin/bash
for file in $(ls /u01/oradata/PROD/*.dbf); do
  echo "Checking $file..."
  dbv file=$file blocksize=8192 | grep -E "(Failing|Corrupt)"
done

シナリオ4：Data Guard 環境での自動修復

-- プライマリで
-- Active Data Guard 設定確認
SELECT db_unique_name, database_role, open_mode 
FROM v$database;

-- スタンバイ側で
-- Real-Time Query 有効化
ALTER DATABASE OPEN;

設定完了後、プライマリの ORA-01578 は自動修復される。

シナリオ5：バックアップなしでの緊急対応

-- 1. Event 10231 で一時回避
ALTER SESSION SET EVENTS '10231 trace name context forever, level 10';

-- 2. 健全なデータを救出
CREATE TABLE emp_salvaged AS SELECT * FROM emp;

-- 3. 元のテーブル置換
DROP TABLE emp;
ALTER TABLE emp_salvaged RENAME TO emp;

-- ⚠️ 破損ブロックのデータは失われる

シナリオ6：DBMS_REPAIR での対処

-- 1. 破損検出
BEGIN
  DBMS_REPAIR.CHECK_OBJECT(
    schema_name => 'SCOTT',
    object_name => 'EMP',
    corrupt_count => v_count
  );
  DBMS_OUTPUT.PUT_LINE('Corrupt: ' || v_count);
END;
/

-- 2. スキップ設定
BEGIN
  DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(
    schema_name => 'SCOTT',
    object_name => 'EMP'
  );
END;
/

シナリオ7：定期監視スクリプト

#!/bin/bash
# check_corruption.sh

result=$(sqlplus -s / as sysdba <<EOF
SET HEADING OFF FEEDBACK OFF
SELECT COUNT(*) FROM v\$database_block_corruption;
EXIT;
EOF
)

if [ "$result" != "0" ]; then
  echo "CORRUPTION DETECTED: $result blocks" | \
    mail -s "URGENT: Oracle Block Corruption" ops@example.com
fi

crontab の詳細は crontab 使い方の記事も参照してください。

シナリオ8：Docker Oracle テスト

docker exec -it oracle-xe sqlplus / as sysdba <<EOF
SELECT * FROM v\$database_block_corruption;
SELECT file#, name FROM v\$datafile;
EOF

Docker 関連は docker daemon 接続エラーの記事、Docker no space left on device の記事も参照してください。

シナリオ9：Rails ヘルスチェック

class OracleHealthCheck
  def self.check_corruption
    result = ActiveRecord::Base.connection.select_value(<<-SQL)
      SELECT COUNT(*) FROM v$database_block_corruption
    SQL
    
    if result > 0
      NotifyOps.critical("Oracle blocks corrupt: #{result}")
      raise "Database integrity issue"
    end
  end
end

シナリオ10：Autonomous DB

Autonomous DB では:
- 自動的な破損検出と修復
- Data Guard 環境が標準
- 通常 DBA 介入不要
- ただし監視は継続

トラブルシューティング

BLOCKRECOVER が使えない

Standard Edition は BLOCKRECOVER 不可、Enterprise Edition 必要。代替: データファイル全体 RESTORE。

バックアップが破損

LIST BACKUP で健全性確認、別のバックアップセット使用。

破損が広範囲

データファイル RESTORE or 表領域再作成。

Data Guard がない

バックアップから RESTORE、または DBMS_REPAIR で救出。

RMAN VALIDATE が遅い

並列チャネル割り当てで高速化:

RMAN> RUN {
  ALLOCATE CHANNEL c1 TYPE DISK;
  ALLOCATE CHANNEL c2 TYPE DISK;
  ALLOCATE CHANNEL c3 TYPE DISK;
  ALLOCATE CHANNEL c4 TYPE DISK;
  BACKUP VALIDATE DATABASE;
}

PostgreSQL 移行

PG は pg_basebackup + pg_verify_checksums、Oracle は RMAN + DBVERIFY。

よくある質問（FAQ）

Q1. 物理破損 vs 論理破損

• 物理: HW/OS/ストレージ起因、CORRUPT/CHECKSUM/FRACTURED
• 論理: Oracle 内部起因、LOGICAL

Q2. BLOCKRECOVER の条件

Enterprise Edition + RMAN バックアップあり。

Q3. Data Guard は必要か

24時間運用ならActive Data Guard 強く推奨。

Q4. DBMS_REPAIR のリスク

破損ブロックのデータは失われる、データ整合性に注意。

Q5. Event 10231

フルテーブルスキャンで破損スキップ、インデックススキャンは不可。

Q6. RMAN バックアップ頻度

毎日 + アーカイブログ 1 時間毎推奨。

Q7. DBVERIFY の実行タイミング

定期的（週次）、問題発生後。

Q8. パフォーマンスへの影響

修復中は該当オブジェクト使用不可、業務時間外推奨。

Q9. Rails での対応

ヘルスチェックエンドポイントで v$database_block_corruption 監視。

Q10. Autonomous DB での挙動

自動修復、通常介入不要、監視は継続。

Q11. 予防策

• ECC メモリ
• RAID10
• Active Data Guard
• 定期 RMAN VALIDATE
• DB_BLOCK_CHECKSUM = FULL

Q12. 監視項目

v$database_block_corruption を毎日確認、0 でなければアラート。

参考リンク

Oracle 公式

• Oracle Database Error Messages: ORA-01578
• Oracle Database Backup and Recovery: Block Media Recovery
• Oracle Database Utilities: DBVERIFY
• DBMS_REPAIR Package

まとめ

ORA-01578: ORACLE data block corrupted の要点を再整理します。

エラーの本質

Oracle データブロックの整合性チェック失敗
→ 物理破損（HW/OS）or 論理破損（Oracle 内部）
→ データ整合性の重大な問題
→ 業務データ損失リスク
→ 緊急対応必須

エラーメッセージの読み方

ORA-01578: ORACLE data block corrupted (file # X, block # Y)
                                             ↑         ↑
                                     ファイル番号  ブロック番号
ORA-01110: data file X: '/path/to/file.dbf'
                    ↑
              物理ファイルパス

物理破損 vs 論理破損

物理破損 (CORRUPT/FRACTURED/CHECKSUM/ALL ZERO):
- HW/OS/ストレージ起因
- RMAN BLOCKRECOVER で修復

論理破損 (LOGICAL):
- Oracle 内部起因
- パッチ + Support 対応

緊急対応の5ステップ

STEP 1: v$database_block_corruption 確認
STEP 2: RMAN VALIDATE で全体スキャン
STEP 3: 影響オブジェクト特定（dba_extents）
STEP 4: バックアップ状態確認
STEP 5: BLOCKRECOVER or RESTORE

10大原因

6つの解決策

# ① RMAN BLOCKRECOVER (推奨)
RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 1027;
RMAN> BLOCKRECOVER CORRUPTION LIST;

# ② データファイル RESTORE
RMAN> RESTORE DATAFILE 4;
RMAN> RECOVER DATAFILE 4;

# ③ Data Guard 自動修復
-- Active Data Guard 環境で自動実行

# ④ DBMS_REPAIR（データ損失あり）
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(...);

# ⑤ Event 10231 スキップ
ALTER SESSION SET EVENTS '10231 trace name context forever, level 10';

# ⑥ CTAS 救出
CREATE TABLE t_backup AS SELECT * FROM t;

診断ツール Top 5

-- ① 破損一覧
SELECT * FROM v$database_block_corruption;

-- ② 影響オブジェクト
SELECT * FROM dba_extents 
WHERE file_id = X AND Y BETWEEN block_id AND block_id + blocks - 1;

# ③ DBVERIFY
dbv file=/path/to/datafile.dbf

# ④ RMAN VALIDATE
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

# ⑤ alert log
tail -200 alert_orcl.log | grep ORA-01578

予防のポイント

1. ECC メモリ搭載
2. RAID10 構成
3. Active Data Guard 環境
4. 定期 RMAN VALIDATE（週次）
5. DBVERIFY オフライン検査（月次）
6. DB_BLOCK_CHECKSUM = FULL
7. 定期バックアップ + アーカイブ
8. 監視スクリプトで v$database_block_corruption 確認
9. UPS で電源保護
10. NFS 避けてローカルディスク

これらの知識は、Oracle DBA の本番運用・障害対応・DR 計画・データ保護・Rails / Java / Python アプリ運用・監視設計・バックアップ戦略・Data Guard 運用・Autonomous DB 管理など、あらゆる場面で活用できます。本記事をブックマークしておけば、ORA-01578 に出会っても冷静に的確に対処できるようになります。

本記事は2026年6月時点の情報をもとに、Oracle Database 19c〜23ai での動作確認・公式ドキュメントに基づき作成しています。Oracle のバージョンにより挙動が異なる場合があるため、最新の情報は Oracle 公式ドキュメント（docs.oracle.com）もあわせてご確認ください。