この記事の要点

Redo Log Buffer は SGA 内の循環バッファ。トランザクションの変更内容（Redo Record）を一時保持 書き出し担当は LGWR (Log Writer)。Redo Log File へ追記 サイズは LOG_BUFFER パラメータ。Oracle 10g 以降は自動管理（手動指定もできるが推奨されない） COMMIT 時 に同期書出が行われる（commit_write で挙動変更可） 監視: V$SGASTAT, V$SYSSTAT, V$LOG, V$LOG_HISTORY

Redo Log Buffer とは

Redo Log Buffer は Oracle インスタンスの SGA (System Global Area) 内に配置される循環型バッファです。データベースに対するすべての変更（INSERT / UPDATE / DELETE / DDL）を Redo Record として記録し、後で LGWR (Log Writer プロセス) が Redo Log File へ書き出します。

Redo は「やり直しログ」とも訳され、インスタンス障害時のリカバリに必須のデータです。Oracle の ACID 保証はこの仕組みに大きく依存しています。

SGA の構成と Redo Log Buffer の位置

+--------------------------------------------------+
|              SGA (System Global Area)            |
|--------------------------------------------------|
|  Database Buffer Cache  (DB ブロックのキャッシュ) |
|  Shared Pool            (SQL 解析結果, Dict)      |
|  Redo Log Buffer        ★ ここ                  |
|  Large Pool             (RMAN / 並列実行)         |
|  Java Pool                                       |
|  Streams Pool                                    |
+--------------------------------------------------+

PGA (Program Global Area): プロセス単位、SORT / HASH 等

動作フロー

1. ユーザーが UPDATE 実行
   ↓
2. サーバプロセスが Database Buffer Cache 上の
   該当ブロックを変更（メモリ上のみ）
   ↓
3. 変更内容を Redo Record として
   Redo Log Buffer に書き込む
   ↓
4. LGWR が以下のタイミングで Redo Log File へ書出:
   - COMMIT 実行時
   - Redo Log Buffer が 1/3 満杯
   - 1 MB の Redo が溜まった
   - 3 秒経過
   - DBWR が ダーティブロックを書く前
   ↓
5. Redo Log File への書込が完了したら
   COMMIT 成功をユーザーに返す

LGWR のトリガ条件

条件	説明
COMMIT	必須。コミットの永続化保証のため
Redo Log Buffer 1/3 充満	容量しきい値
1 MB の Redo 蓄積	絶対容量しきい値
3 秒経過	タイムアウト書出
DBWR 書出直前	Write-Ahead Logging 原則

重要なのは Write-Ahead Logging (WAL) 原則: データブロックを Redo Log より先に書いてはいけない。これがリカバリ可能性の根幹です。

サイズ設定: LOG_BUFFER

-- 現在の Redo Log Buffer サイズ確認
SELECT name, value
FROM v$parameter
WHERE name = 'log_buffer';

-- V$SGASTAT で実際の使用状況
SELECT pool, name, bytes
FROM v$sgastat
WHERE name LIKE '%redo%';

-- 手動指定（Oracle 10g 以降は非推奨、自動管理に任せる）
ALTER SYSTEM SET log_buffer = 16M SCOPE=SPFILE;
-- ※ 動的変更不可、再起動が必要

SHUTDOWN IMMEDIATE;
STARTUP;

Oracle 10g 以降、SGA_TARGET / MEMORY_TARGET による自動メモリ管理が推奨され、LOG_BUFFER も自動調整されます。デフォルトは CPU 数 × 512KB 程度（最低 2MB）。

COMMIT 時の挙動制御

-- commit_write パラメータ
-- IMMEDIATE / BATCH と WAIT / NOWAIT の組合せ

-- デフォルト: IMMEDIATE, WAIT
ALTER SYSTEM SET commit_write = 'IMMEDIATE,WAIT';
-- LGWR が Redo Log File に書き終えるまで待つ（安全）

-- 高速モード（データ損失リスクあり）
ALTER SYSTEM SET commit_write = 'IMMEDIATE,NOWAIT';
-- LGWR の完了を待たずにユーザーに OK を返す
-- → クラッシュ時にコミット済データが消える可能性

-- セッション単位
ALTER SESSION SET commit_write = 'BATCH,NOWAIT';

-- バッチ処理の高速化用途のみで使用
-- 通常業務 (OLTP) では絶対に NOWAIT を使わない

Redo Log File との関係

Redo Log Buffer から書き出される先は Online Redo Log File。複数（通常 3〜4 グループ）あり、循環的に使われます。満杯になると Log Switch が発生し、次のグループへ。

-- Redo Log File 構成確認
SELECT group#, members, bytes/1024/1024 AS mb, status
FROM v$log;

GROUP#  MEMBERS  MB    STATUS
1       2        100   INACTIVE
2       2        100   CURRENT
3       2        100   INACTIVE

-- メンバー（多重化）
SELECT group#, member FROM v$logfile;

-- Log Switch を強制
ALTER SYSTEM SWITCH LOGFILE;

-- 履歴
SELECT * FROM v$log_history ORDER BY first_time DESC FETCH FIRST 20 ROWS ONLY;

ARCH (Archiver) との連携

ARCHIVELOG モードでは、Log Switch のタイミングで ARCH プロセスが Online Redo Log File を Archived Redo Log としてアーカイブ先にコピーします。これによりリカバリ用の履歴が永続化されます。

-- ARCHIVELOG モード確認
ARCHIVE LOG LIST;

-- NOARCHIVELOG → ARCHIVELOG 切替（要 MOUNT 状態）
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- アーカイブ先確認
SHOW PARAMETER db_recovery_file_dest;
SHOW PARAMETER log_archive_dest;

-- 強制アーカイブ
ALTER SYSTEM ARCHIVE LOG CURRENT;

監視ビュー

ビュー	用途
V$SGASTAT	SGA 各プールの使用状況
V$SYSSTAT	redo size, redo writes 統計
V$LOG	Online Redo Log File 状態
V$LOGFILE	Redo Log File メンバー
V$LOG_HISTORY	Log Switch 履歴
V$INSTANCE_RECOVERY	クラッシュリカバリ予測
V$SESSION_WAIT	log file sync 等の待機

「log file sync」待機イベント

もっとも有名な Redo 関連の待機イベント。COMMIT 時に LGWR の書出を待つ時間です:

-- log file sync 待機の確認
SELECT event, total_waits, time_waited / 100 AS time_sec
FROM v$system_event
WHERE event IN ('log file sync', 'log file parallel write')
ORDER BY time_waited DESC;

-- セッション単位
SELECT sid, event, seconds_in_wait
FROM v$session_wait
WHERE event = 'log file sync';

-- 対処:
-- 1. Redo Log File を高速ディスクに（SSD / NVMe）
-- 2. Redo Log File サイズを大きく（Log Switch 頻度減）
-- 3. COMMIT 回数を減らす（バッチコミット）
-- 4. Redo Log File を分散ディスクに
-- 5. NOLOGGING でバルクロード（リカバリ要件と相談）

Hot Backup 時の挙動

オンラインバックアップ中（BEGIN BACKUP 〜 END BACKUP）は、データブロックの fractured block 問題を避けるため、Redo Log Buffer / Redo Log File への書込が増加します（ブロック全体を Redo に含める）。バックアップ完了で通常モードに戻ります。

Redo Apply (Data Guard Standby)

Oracle Data Guard では、プライマリの Redo Log がスタンバイ DB に転送され、Redo Apply（MRP プロセス）が適用することで、リアルタイムレプリケーションを実現します。

• SYNC: 同期転送、データ損失ゼロ（性能影響あり）
• ASYNC: 非同期転送、若干の遅延と損失リスク
• FAR SYNC: 地理的に遠いスタンバイ向けの中継構成

リカバリーの基本

インスタンスクラッシュ → 再起動

1. STARTUP 中、SMON プロセスが
   Online Redo Log File を読み直し
   ↓
2. 最後のチェックポイント以降の変更を
   Database Buffer Cache に再適用 (Roll Forward)
   ↓
3. UNDO セグメントから未コミットトランザクションを
   元に戻す (Roll Back)
   ↓
4. データベースオープン

メディア障害 → RMAN リカバリ

1. バックアップから データファイル復元
2. Archived Redo Log + Online Redo Log を
   順次適用 (Recover)
3. RESETLOGS でオープン

FAQ

Q: Redo Log Buffer は大きくすればするほど良い？
A: いいえ。一定サイズを超えると効果が頭打ち、メモリの無駄になります。多くの場合 3MB〜16MB で十分。自動管理に任せましょう。

Q: NOLOGGING でロードしたデータはリカバリされない？
A: 正しいです。INSERT /*+ APPEND */ + NOLOGGING でロードしたデータはメディア障害時に消失します。直後の バックアップが必須です。

Q: 「log file sync」が高い原因は？
A: 多くは I/O 遅延（Redo Log File が遅いディスク）または COMMIT 頻度過多（行単位コミット）。バッチコミットと SSD 配置で改善します。

Q: Redo Log File を多重化する意味は？
A: 1 つのメンバーがディスク障害で読めなくても、もう一方が生きていればリカバリ可能。異なる物理ディスクに置くのがベストプラクティス。