在 Oracle 資料庫進行 commit 的行為就會產生 log file sync 事件，對於一個交易型的系統來說，理解 log file sync 是非常重要的一件事， log file sync 等待時間的長短往往直接決定了交易型系統的整體效能。
log file sync 等待事件指的是 commit 從開始到結束整個過程，流程大致如下 :
user session 執行 commit 指令，此時會通知 LGWR 將 redo buffer 的信息寫入 redo log ， LGWR 接收到通知後，開始進行 I/O 寫入的動作，完成後告知 user session 完成整個 commit 的流程。
log file sync 一定會伴隨著 log file parallel write 事件，也就是中間 LGWR 進行 I/O 寫入的過程，當發生 log file sync 的效能問題時，必須與 log file parallel write 等待事件一起分析，因為有可能是 I/O 效能不佳進而增加整個 log file sync 等待時間。
一般 log file sync 等待時間過長有幾種可能 :
- redo log 切換太頻繁
Redo Log 切換太頻繁往往是影響 log file sync 等待時間的主因，頻繁的 commit 或 rollback ，或是 redo log 的大小與數量不合適都有可能造成 redo log 切換太頻繁。
- LGWR 的 I/O 性能不佳
I/O 性能不佳也是造成 log file sync 事件拉長的原因之一， LGWR 寫入的速度來不及處理頻繁的 commit 行為，也就是 log file parallel write 的時間過長。
從 AWR Report 看到 log file sync 等待事件時，可以從幾個方向開始分析 :
首先必須檢查資料庫的 alert log ，先確認是否有 redo log 切換太頻繁的問題，如果 alert log 有顯示出大量的 Checkpoint not complete 訊息，那就表示 redo log 因為來不及切換導致等待事件發生 :
如果有這種現象，那就表示 redo log 數量不足，或者是 redo log 大小不合適，那麼只需調整 redo log 數量與大小即可。
若是沒有這個現象，那就表示沒有 redo log 切換太頻繁的問題，此時就很有可能是 I/O 效能的問題，可以檢查 AWR 的 Background Wait Events 是否 log file parallel write 的等待時間過長，或者是從 lgwr 的 trace file 檢查 LGWR 的寫入速度 :
以這個例子來說， LGWR 只有寫入幾 KB 或是幾十 KB 就需要十幾秒甚或至百秒，那就可以確定 I/O 的效能有問題，此時就必須請系統管理員協助處理 I/O 效能的問題。
當發生 log file sync 效能問題時，除了檢查 alert log 、 lgwr trace 之外， DB 層面還可以收集 ASH (dba_hist_active_sess_history 、 wrh$_active_session_history) 資訊 ，作業系統層面可以收集監控資訊如 OSWatcher 、 NMON …等，更進一步可以執行 strace(Linux) 、 truss(AIX) 例如 :
# strace -rfttT -o /tmp/start_trace.out -p <PID_of_ LGWR process> |
透過 strace 可掌握 I/O 行為實際停滯的 system call ，對於深入分析 log file parallel write 等待事件的效能根因具有相當大的幫助。
總結 log file sync 等待事件對交易型系統（OLTP）的效能影響相當重大。建議將 redo log 放置於效能較佳、延遲較低的磁碟設備上；同時在應用程式設計上，對交易行為盡量採用批次處理，降低 commit 的發生頻率。透過這些做法，有助於有效縮短 log file sync 的等待時間，進而提升整體交易效能與系統吞吐量。
