在 Oracle 數據庫中,log file sync 是一個非常常見、但也極容易被誤解的等待事件。
它并不一定代表磁盤慢、也不一定是 LGWR 有問題,更多時候它反映的是 提交路徑上的“同步等待”。
本文將結合原理、架構、以及多個真實生產場景,對 log file sync 進行系統性拆解。
一、log file sync 是什么?
log file sync 表示:
前臺會話在執行 COMMIT / ROLLBACK 時,等待 LGWR 將對應 redo 寫入 redo log 文件并確認完成。
只要用戶會話沒有收到 LGWR 的“寫完成”信號,就會一直處于 log file sync 等待狀態。
二、log file sync 原理圖
1. 單實例提交路徑原理


基本流程如下:
- User Session 執行
COMMIT - 提交請求通知 LGWR
- LGWR 將 redo buffer 寫入 redo log file
- 寫入成功后,LGWR 通知 User Session
- User Session 返回 commit 成功
只要第 3、4 步被拖慢,就會產生 log file sync。
三、log file sync 的主要原因分類
原因一:事務頻繁提交 / 回退(過度 commit / rollback)
1. 事務過度提交(最常見原因)
事務過度提交是引起 log file sync 等待事件的主要原因之一。
- 默認情況下,每次事務提交:
- LGWR 立即(immediate)
- 同步(wait) 寫 redo
- 提交越頻繁:
- LGWR 寫日志越頻繁
log file sync等待越明顯
本質問題不是 I/O 慢,而是 commit 太多。
解決思路
最優解(應用層):
- 將多個小事務合并為一個大事務
- 減少無意義的頻繁 commit
但現實中:
- 修改應用成本高
- 依賴應用廠商配合
DB 端可用手段(10g 以后)
Oracle 10g 起提供參數:
commit_write = nowait,batch
含義:
? 提交時不立即寫日志
? redo 采用異步 + 批量寫
?? 風險提示:
? 數據庫異常宕機時,可能丟失最近一小部分事務
? 需要業務可接受
其他輔助方式
? 使用臨時表
? 使用 NOLOGGING
? 盡可能減少 redo 產生量
原因二:存儲 I/O 資源緊張,LGWR 寫入緩慢
1. LGWR 的 I/O 特性
? 順序寫
? 小 I/O
? 對 IOPS 非常敏感
一旦存儲繁忙,LGWR 寫入速度下降,log file sync 就會出現。
判斷方法
方法一:觀察操作系統磁盤負載
? AIX:topas
? Linux:iostat, sar


方法二:對比等待事件時間
? log file parallel write
? log file sync
如果兩者時間 接近,說明問題在存儲。
查看等待分布示例
SELECT event, wait_time_milli, wait_count
FROM v$event_histogram
WHERE event = 'log file parallel write';
示例輸出:
WAIT_TIME_MILLI WAIT_COUNT
1 22677
2 424
4 141
8 340
16 1401
32 812
64 391
128 21
256 6
解決方案
1. redo log 遷移到獨立、空閑、性能更高的磁盤
2. 視情況遷移 UNDO 表空間,釋放 I/O 壓力
3. redo log 有多 member 時,可減少 member 數量
原因三:短時間業務量過大(redo 激增)
常見于:
? 批量 DML
? 夜間批處理
? 數據遷移
分析建議
? 分析 redo / archive 生成趨勢
? 判斷是否業務突增而非系統異常
? 觀察業務量是否平穩
原因四:CPU 資源緊張,LGWR 搶不到時間片
現象特征
? log file sync 很高
? log file parallel write 每次僅 1~2ms
說明:
LGWR 寫得并不慢,而是 拿不到 CPU
解決方案
1. 增加 CPU / 優化高 CPU SQL(效果最好,成本最高)
2. OS 層面提高 LGWR 優先級(renice)
3. 綁定 LGWR 到指定 CPU
4. 設置隱含參數:
_high_priority_processes
原因五:redo buffer 太小
? redo buffer 太小 → 寫入過于頻繁
? redo buffer 太大 → 單次寫入量過大
建議
? 適當調大
? 調整后持續觀察
? 不建議一味追求“大”
原因六:redo log 文件太小 / 組數不足
建議配置
? redo 文件大小:
? 至少 500MB
? 繁忙系統建議 1G / 2G
? redo log 組數:
? 至少 3 組
? 繁忙系統建議 5 組以上
四、RAC 場景下的特殊原因
原因七:RAC 節點之間 SCN 同步(Commit SCN)
原理說明
RAC 中為了保證一致性讀,需要同步 commit SCN。
? Lamport SCN
? Immediate Commit Propagation(BOC)
BOC 提交流程
流程簡述:
1. User Session commit
2. LGWR 寫 redo
3. LGWR 將 commit SCN 廣播給遠端 LMS
4. 遠端 LMS 同步 SCN
5. 全部確認后,commit 才返回成功
解決思路
1. 檢查 LMS 進程數量
2. 檢查 CPU 是否足夠
3. 檢查私網通信
4. 必要時關閉 BOC:
_immediate_commit_propagation = false
原因八:RAC 節點之間 CR 塊傳遞
原理
? current block 修改后
? redo 必須寫入完成
? 才能通過 LMS 傳給其他節點
解決方案
1. 減少跨節點訪問
2. 設置:
_cr_server_log_flush = false
原因九:控制文件爭用
LGWR 寫 redo 時需要更新控制文件。
? RMAN 高頻操作
? 并發控制文件更新
? 導致 enq: CF–contention
當 LGWR 拿不到 CF 鎖時,前臺會話可能出現 log file sync。
五、OLTP 系統的一個關鍵參數建議
對于交易型(OLTP)系統:
ALTER SYSTEM SET “_use_adaptive_log_file_sync” = FALSE SCOPE=SPFILE SID=’*’;
含義:
? 固定使用 post/wait 機制
? 避免 adaptive 模式下產生過多 log file sync
六、總結
log file sync 不是一個簡單的“磁盤慢”問題,而是:
事務提交、redo 寫入、CPU 調度、RAC 同步等多因素共同作用的結果。
排查建議:
1. 先看 commit 頻率
2. 再看 log file parallel write
3. 同時結合 CPU、存儲、RAC 架構
4. 避免“只調參數、不看業務”的誤區
它本質上,是 Oracle 作為一臺高度同步系統的真實體現。




