「log file sync」イベント

◆「log file sync」イベント
Oracle データベースでは、ログファイル同期は、ユーザーセッションがトランザクションをコミットまたはロールバックし、REDO ログバッファの内容がディスク上のオンライン REDO ログファイルにフラッシュされるまで待機する必要があるときに発生する待機イベントです。

ログファイル同期中に何が起こるか
セッションは COMMIT または ROLLBACK を発行します。
Oracle は、ログライター (LGWR) プロセスに、そのトランザクションのすべての REDO エントリをメモリ内の REDO ログバッファからオンライン REDO ログファイルに書き込むように指示します。
セッションは、LGWR が書き込みの完了を確認するまで待機します (永続性 (ACID の「D」) を確保するため)。
待機時間はログファイル同期（log file sync）として記録されます。

◆要点
Trigger: COMMIT or ROLLBACK
Related Event: log file parallel write (LGWR’s actual I/O to redo logs)
Impact: High log file sync wait times can slow down transaction throughput.

待機クラス: コミット
Wait Class: Commit

トリガー: COMMIT または ROLLBACK
関連イベント: ログファイル並列書き込み (LGWR の REDO ログへの実際の I/O)
影響: ログファイル同期の待機時間が長いと、トランザクションのスループットが低下する可能性があります。

ログファイル同期の待機時間が長くなる一般的な原因
・REDO ログの I/O サブシステムの低速化 (ディスクレイテンシ)
・アプリケーションコードでの頻繁なコミット (例: 行挿入ごとにコミット)
・REDO ログの競合 (同時にコミットするセッションが多すぎる)
・REDO ログバッファが小さいため、フラッシュが頻繁に発生する
・LGWR プロセスのボトルネック (CPU 不足、OS スケジューリングの遅延)

◆診断方法
平均待機時間と頻度を確認できます。

SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event = 'log file sync';

SELECT event, total_waits, time_waited, average_wait

FROM v$system_event

WHERE event = 'log file sync';

SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event = 'log file parallel write';

SELECT event, total_waits, time_waited, average_wait

FROM v$system_event

WHERE event = 'log file parallel write';

SELECT name, phyrds, phywrts, readtim, writetim
FROM v$filestat
WHERE name LIKE '%redo%';

SELECT name, phyrds, phywrts, readtim, writetim

FROM v$filestat

WHERE name LIKE '%redo%';

◆チューニング戦略
コミット頻度の削減
行ごとにコミットするのではなく、一括コミットします。

・REDOログのI/Oパフォーマンスの向上
REDOログを高速ストレージ（NVMe、SSD）に配置します。
競合を避けるため、REDOログには別々のディスクを使用してください。

・REDOログ・バッファ・サイズを増やしてください。

ALTER SYSTEM SET log_buffer = 64M SCOPE=SPFILE;

1	ALTER SYSTEM SET log_buffer = 64M SCOPE=SPFILE;

（再起動が必要です。バッファが小さすぎる場合にのみ役立ちます。）

・LGWRパフォーマンスを最適化してください。
LGWRに十分なCPU優先度があることを確認してください。
OSレベルのI/Oボトルネックを回避してください。
コミット・ストームをチェックしてください。
コミットが過剰になっているセッションを特定してください。

SELECT s.sid,
       s.serial#,
       s.username,
       t.name,
       v.value AS commits
FROM v$sesstat v
JOIN v$statname t ON v.statistic# = t.statistic#
JOIN v$session s ON v.sid = s.sid
WHERE t.name = 'user commits'
ORDER BY commits DESC;

SELECT s.sid,

s.serial#,

s.username,

t.name,

v.value AS commits

FROM v$sesstat v

JOIN v$statname t ON v.statistic# = t.statistic#

JOIN v$session s ON v.sid = s.sid

WHERE t.name = 'user commits'

ORDER BY commits DESC;

◆経験則：
ログファイル同期の平均待機時間は、最新のストレージでは理想的には 1 ミリ秒未満である必要があります。
これよりも大幅に長い場合は、I/O レイテンシとコミットパターンを調査してください。

ログファイル同期（log file sync）の待機時間を削減するための、実践的でステップバイステップのOracleチューニング・チェックリスト

これは、実際のOracleパフォーマンス・チューニングの実践とAWR/ASH分析に基づいています。

Oracle ログファイル同期チューニング・チェックリスト
1. 問題の確認
チューニングを行う前に、ログファイル同期が実際に最上位の待機イベントであることを確認してください。

— AWRまたはV$SYSTEM_EVENTから
SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event = ‘log file sync’;

— LGWRのI/O時間と比較
SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event = ‘log file parallel write’;

◆解釈：
ログファイル同期の平均待機時間がログファイル並列書き込みの平均待機時間より短い場合 → I/Oバウンド。
ログファイルの同期がログファイルの並列書き込みより優先される場合 → CPU スケジューリング / コミットストームの問題。
2. コミット頻度の分析
過剰なコミットは LGWR フラッシュの頻繁な発生原因となります。

SQL

— コミット数上位セッション
SELECT s.sid, s.serial#, s.username, v.value AS commits
FROM v$sesstat v
JOIN v$statname t ON v.statistic# = t.statistic#
JOIN v$session s ON v.sid = s.sid
WHERE t.name = ‘user commits’
ORDER BY commits DESC;

対策:

アプリケーションコード内でコミットを一括処理します。
どうしても必要な場合を除き、ループ内での COMMIT は避けてください。
3. REDO ログの I/O レイテンシを確認します。
REDO ログは高速な専用ストレージ上に配置する必要があります。

Sql

コードをコピー
SELECT name, phyrds, phywrts, readtim, writetim,
ROUND(DECODE(phywrts,0,0,writetim/phywrts),3) AS avg_write_ms
FROM v$filestat
WHERE name LIKE ‘%redo%’;
アクション:

平均書き込み時間を1ミリ秒未満にすることを目標とする。
REDOログをNVMe/SSDまたは低レイテンシのSANに移行する。
データファイルとアーカイブログとは別のディスクを使用する。
4. REDOログ構成を最適化する
サイズ: スイッチ数を減らすため、より大きなREDOログファイルを使用する（例: 1～4GB）。
グループ: 最低3グループ、高同時実行性を実現するにはそれ以上が理想的。
配置: 異なるディスクにREDOログを多重化する。
SQL

コードをコピー
ALTER DATABASE ADD LOGFILE GROUP 4 (‘/fastdisk/redo04a.log’、’/fastdisk2/redo04b.log’) サイズ 2G;
5.REDOログバッファの調整
REDO ログバッファが小さすぎる場合、LGWR はより頻繁にフラッシュします。

SQL

コードをコピー
SHOW PARAMETER log_buffer;
アクション：

常に満杯の場合は増加します (V$SYSSTAT で REDO バッファ割り当ての再試行を確認してください)。
例：
SQL

コードをコピー
ALTER SYSTEM SET log_buffer = 64M SCOPE=SPFILE;
(再起動が必要です)

6. LGWR CPU スケジューリングを確認する
ログファイル同期 >> ログファイル並列書き込みの場合、LGWR が遅れる可能性があります。

アクション：

LGWR の OS 優先順位が高いことを確認します。
他のプロセスによる CPU の枯渇を回避します。
Linuxの場合：
Bash

コードコピー
ps -eo pid,comm,pri,ni,pcpu | grep lgwr
7. コミットストームを特定する
複数のセッションが同時にコミットすると、待機時間が急増する可能性があります。

SQL

コードコピー
SELECT sample_time, COUNT(*) AS commits
FROM v$active_session_history
WHERE event = ‘log file sync’
GROUP BY sample_time
ORDER BY commits DESC;
アクション：

アプリケーションロジック内でコミットをずらします。
一括操作を使用します。
8. AWR/ASHを使用して詳細分析を行います。
AWRレポートから：

「Top Timed Events」→「log file sync position」を確認します。
「log file sync」と「log file parallel write」を比較します。
「Instance Activity Stats」→「user commits rate」を確認します。
ASH から:

SQL

コードをコピー
SELECT event, COUNT(*)
FROM v$active_session_history
WHERE event = ‘log file sync’
GROUP BY event;
9. 詳細オプション
COMMIT WRITE: コミット動作（非同期 vs バッチ）を制御します。注意して使用してください。
RAC: RAC では、ログファイル同期はインターコネクトのレイテンシの影響を受ける可能性があります。
フラッシュストレージ: 永続メモリ（PMEM）または Optane を使用すると、待機時間を大幅に短縮できます。
10. チューニング後の検証
変更後:

SQL

コードをコピー
— 改善を確認
SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event = ‘log file sync’;
変更前と変更後の待機時間とトランザクションスループットを比較します。

✅ 目安となる目標値：

平均待機時間：1ミリ秒未満（最新のSSD/NVMe）
コミットレート：ビジネスニーズとのバランス
REDOログ書き込みレイテンシ：1ミリ秒未満

テンプレートサイト

－サンプル、テンプレート－

コメントを残す