Adaptive Log File Sync 為 Oracle 12c 的新功能，目的在於減少 log file sync 等待事件的延遲，其核心概念在於 user commit 後的行為模式分為兩種 : Post/wait 與 Polling 。
- Post/wait
為 user session 執行 commit 時的預設機制。當 user 發出 commit 後，會通知 LGWR 進行 redo log 的寫入；在此期間， user session 會進入等待（sleep）狀態，待 LGWR 完成 I/O 寫入並回報後，才會喚醒該 session ；當 user session 收到 LGWR 的回應，即表示此次 commit 已完成，並可繼續後續操作。
這個模式之下好比老闆交代員工一個任務之後，老闆就不管這個任務的進度直到員工主動回報完成，也就是 user 使用 commit 賦予 LGWR 任務之後， user session 就不再管此事，直到 LGWR 告知它任務完成了。
好處是當 user session進入等待 (sleep) 時不會消耗 CPU 資源；壞處是 user session 需要等 LGWR 回報後才能喚醒，這個過程會造成些許的延遲，當 commit rate 極高時， LGWR 必須逐一發送信號給每一個在 log file sync 等待隊列中的 User Session ，這種「一對多」的喚醒工作會讓 LGWR 成為系統瓶頸。
- Polling
為 Adaptive Log File Sync 機制中新增的模式，與 Post/wait 模式最大的差別在於， user 執行 commit 之後， user session 不會進入等待 (sleep) 模式，而是不斷的主動輪詢 LGWR 完成了沒，主動詢問 LGWR 且收到完成的訊息之後，即表示此次 commit 已完成。
這個模式用同一個比喻下，就好比老闆交代員工一個任務，並且老闆持續追蹤員工進度直到任務完成，也就是 user 使用 commit 賦予 LGWR 任務之後， user session 會主動持續關注 LGWR 是否已經完成它的任務了。
好處是 LGWR 不需要喚醒 user session 的動作，減少延遲，在高 commit rate 的場合中表現較佳；缺點是 user session 必須消耗 CPU 資源來持續輪詢 LGWR 是否完成，如果系統 CPU 資源較緊的話就不適合這個模式。
Adaptive Log File Sync 會依據系統的可用資源來自動切換這兩種模式，用以達到 log file sync 最佳的吞吐量，觀察 LGWR 的 trace 可以知道目前是使用何種模式進行 :
*** 2012-10-02 08:15:47.050 Log file sync switching to polling Current scheduling delay is 4 usec
*** 2012-10-02 08:16:23.325 Log file sync switching to post/wait Current approximate redo synch write rate is 8 per sec |
從 AWR 或者是 v$sysstat 也可以觀察到是否有使用 polling 模式 :
早期這個功能剛推出的時候，於 RAC 環境可能會遭遇到 Bug 25178179 : Several sessions wait on 'log file sync' in a RAC environment ，這個 Bug 導致於 Polling 模式效能不佳，具體的現象為使用 Polling 模式、 log file sync 時間很長但 log file parallel write 時間很短。不過這個 Bug 已經於多數 12.2 的版本進行修復了，在現今的環境當中是不會再遇到這個問題。
最後提一下，如果系統 CPU 資源較緊，不希望使用到 Polling 模式，可以設定隱藏參數 "_use_adaptive_log_file_sync" = FALSE 來關閉 adaptive log file sync 功能，參數可以動態更改。
