過去バージョン

REDOログの役割

OracleのREDOログは、すべてのデータ変更を記録するトランザクションログです。役割は2つ:

• クラッシュリカバリ: インスタンス障害時、COMMIT 済の変更を再現
• メディアリカバリ: データファイル消失時、バックアップ＋REDO で時点復旧

COMMIT 時点で REDO バッファが LGWR プロセスにより必ずディスクに書かれます（fsync）。これがACID の D（永続性）を保証します。

Online Redo Log と Archive Redo Log

Group と Member（多重化）

1つの REDO ロググループは複数の Member（同じ内容の物理ファイル）で構成できます。ディスク障害に備えた多重化です。

[ Group 1 ]    [ Group 2 ]    [ Group 3 ]
 Member a       Member a       Member a
 Member b       Member b       Member b
   ↑同内容       ↑同内容        ↑同内容
   ディスク1     ディスク1      ディスク1
   ディスク2     ディスク2      ディスク2

LGWR は Group 内の全 Member に同じ REDO を書き込む。
1 つ壊れても他の Member から復旧可能。

状態確認: v$log と v$logfile

-- グループの状態
SELECT group#, sequence#, members, status FROM v$log;

-- GROUP#  SEQUENCE#  MEMBERS  STATUS
-- ------  ---------  -------  ----------
--     1        100        2   ACTIVE       ← まだチェックポイント未完了
--     2        101        2   CURRENT      ← LGWR が今書いている
--     3         99        2   INACTIVE     ← 再利用可能

-- メンバーの物理ファイル位置と状態
SELECT group#, member, status FROM v$logfile;

-- GROUP#  MEMBER                       STATUS
-- ------  ---------------------------  ------
--     1   /u01/oradata/redo01a.log
--     1   /u02/oradata/redo01b.log
--     2   /u01/oradata/redo02a.log     INVALID  ← 故障

-- アーカイブ済の REDO 一覧
SELECT sequence#, name FROM v$archived_log ORDER BY sequence# DESC FETCH FIRST 10 ROWS ONLY;

STATUS の意味

ARCHIVELOG モード

既定の NOARCHIVELOG モードでは Online Redo が上書きされて消えます。本番DBは必ず ARCHIVELOG モードに変更し、Archive Redo を保管します。

-- 現在のモード確認
ARCHIVE LOG LIST;
SELECT log_mode FROM v$database;    -- ARCHIVELOG / NOARCHIVELOG

-- NOARCHIVELOG → ARCHIVELOG への切替
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- アーカイブ先の設定
ALTER SYSTEM SET log_archive_dest_1 = 'LOCATION=/u01/arch' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_dest_2 = 'LOCATION=/u02/arch' SCOPE=BOTH;

-- 手動でログ切替（テスト用）
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM ARCHIVE LOG CURRENT;

Group / Member の追加・削除

-- グループ追加（多重化2 Member、各 100MB）
ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/oradata/redo04a.log', '/u02/oradata/redo04b.log') SIZE 100M;

-- 既存グループに Member 追加
ALTER DATABASE ADD LOGFILE MEMBER '/u03/oradata/redo01c.log' TO GROUP 1;

-- Member 削除
ALTER DATABASE DROP LOGFILE MEMBER '/u03/oradata/redo01c.log';

-- Group 削除（CURRENT/ACTIVE は不可、INACTIVE のみ）
ALTER DATABASE DROP LOGFILE GROUP 4;

リカバリの基本フロー

クラッシュリカバリ（自動）
─────────────────────────
インスタンス停止 → STARTUP
1. ロールフォワード: Online Redo を適用して、COMMIT 済の変更を再現
2. ロールバック   : 未 COMMIT のトランザクションを巻き戻し
3. DB OPEN

メディアリカバリ（手動）
─────────────────────────
データファイル消失 → 復旧手順
1. RMAN でバックアップから データファイル復元
2. RECOVER DATABASE で Archive Redo を順次適用
3. オープン直前の Online Redo まで適用
4. ALTER DATABASE OPEN

-- RMAN でのリカバリ例
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

-- 不完全リカバリ（特定時点まで）
RMAN> RUN {
  SET UNTIL TIME "TO_DATE('2026-06-11 10:00:00','YYYY-MM-DD HH24:MI:SS')";
  RESTORE DATABASE;
  RECOVER DATABASE;
  ALTER DATABASE OPEN RESETLOGS;
}

LogMiner で過去のDMLを掘り起こす

誤って DELETE / UPDATE してしまった場合、LogMiner で REDO ログを解析し、復元用 SQL を取得できます。

-- 解析対象ログを追加
EXEC DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/u01/arch/1_100_xxx.arc', OPTIONS => DBMS_LOGMNR.NEW);
EXEC DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/u01/arch/1_101_xxx.arc', OPTIONS => DBMS_LOGMNR.ADDFILE);

-- 解析開始
EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

-- DML を確認
SELECT scn, timestamp, username, operation, sql_redo, sql_undo
FROM   v$logmnr_contents
WHERE  table_name = 'ORDERS'
  AND  operation IN ('UPDATE','DELETE');

-- SQL_UNDO を実行すれば変更を取り消せる
-- 解析終了
EXEC DBMS_LOGMNR.END_LOGMNR;

運用のベストプラクティス

• Online Redo は3〜5 グループ × 2〜3 Member 多重化が基本
• ファイルサイズは15〜30 分でログ切替するくらいに調整
• Archive ログは別ディスク・別サーバへ転送し、定期的にバックアップ
• RAC 構成ではインスタンスごとに REDO Threadを持つ
• Data Guard でスタンバイDBへ REDO を転送し DR 構成

FAQ

Q: REDO ログを大きくする / 小さくする基準は？
A: ピーク時に 15〜30 分で 1 切替が目安。短すぎるとアーカイブが急増、長すぎるとリカバリ時間が伸びます。

Q: NOARCHIVELOG モードのまま運用していい？
A: 開発/検証だけ。本番は必ず ARCHIVELOG。データファイル障害時にバックアップ時点までしか戻れず、それ以降のデータは失われます。

Q: REDO ログを誤って削除してしまった
A: INACTIVE グループなら ALTER DATABASE CLEAR LOGFILE GROUP n で再作成。CURRENT/ACTIVE はバックアップから復旧必要。