一、什麼是LOG FILE SYNC等待事件？
當一個用戶會話提交，那個用戶產生的所有redo需要從內存刷新到重做日誌文件，使事務對數據庫的修改永久化。
在提交時，用戶會話會通知 LGWR 把日誌緩衝區中的信息寫到重做日誌文件（當前所有未被寫入磁盤的 redo 信息，包括本
次會話的 redo 信息）。當 LGWR 發現寫操作完成後，它會通知用戶會話。當等待 LGWR 通知確認所有 redo 已經安全的
保存到磁盤的過程時，用戶會話會等待'log file sync'。
用戶會話顯示等待'log file sync'，是用戶會話通知 LGWR 和 LGWR 通知用戶的寫操作完成之間的時間。
二、用戶應該蒐集那些信息，來初步分析'log file sync'等待事件？
1、'log file sync'等待在可接受範圍的類似時間的 AWR 報告，作爲用於比較的性能基線
2、'log file sync'等待很嚴重期間的 AWR 報告 注：2 個報告應在 10-30 分鐘之間。
3、LGWR 日誌文件（在12.2版本以上還需收集LGnn日誌文件），當日志寫入較慢的時候，LGWR 日誌文件將會顯示警告信息
三、什麼原因造成了很高的’log file sync’等待？
1、影響LGWR的I/O性能問題
比較log file sync 和 log file parallel write 的平均等待時間
等待事件'log file parallel write'表示 LGWR 正在等待寫 redo 操作。該事件的持續時間就是等待 IO 操作部分的時間。
上面的例子顯示了'log file sync' 和 'log file parallel write' 都有很高的等待時間
如果'log file sync'的時間消耗在'log file parallel write'上的比例高，那麼大部分的等待時間是由於 IO（等待 redo 寫
入）。應該檢查 LGWR 在 IO 方面的性能。作爲一個經驗法則，'log file parallel write'平均時間超過 20 毫秒, 意味着 IO
子系統有問題。
建議：
- 與系統管理員一起檢查重做日誌所在的文件系統以及本地卷的位置，以提高 IO 性能。
- 不要把重做日誌放在需要額外計算的較老的或者複雜的RAID上，比如 RAID-5或者RAID-6或者只有很少cache部件的存儲上
- 不要把重做日誌放在上一代或者較老的Solid State Disk (SSD)磁盤上雖然通常情況下，SSD 寫入性能好於平均水平，他們可能會遇到寫峯值,從而導致大量的嚴重'log file sync'等待並引發數據庫性能不穩定或者hung住(關於這一點您需要詳盡的測試，因爲我們也碰到一些即使SSD的寫性能不穩定但數據庫性能仍然可以接受的系統)
- (Engineered Systems (Exadata, SuperCluster 和 Oracle Database Appliance) 除外，因爲在這些系統上已經爲使用SSD來存放重做日誌而做了額外的優化)
- 監控其他可能需要寫到相同路徑的進程，確保該磁盤具有足夠的帶寬，足以應付所要求的容量。如果不能滿足,增加硬盤或者更快的磁盤設備或者把這些文件分散到不同的磁盤設備。
- 確保 LOG_BUFFER 不要太大，一個非常大的 log_buffer 的不利影響就是刷新需要更長的等待時間。當緩衝區滿了的時候，它必須將所有數據寫入到重做日誌文件。LGWR 將一直等待,直到最後的 I/O 完成。
2、檢查在線重做日誌是否足夠大
每次重做日誌切換到下一個日誌時，會執行'log file sync'操作，以確保下一個日誌開始之前信息都寫完。 標準建議是日誌切換最多 15 至 20 分鐘一次。 如果切換比這更頻繁，那麼將發生更多的'log file sync'操作，意味着更多的會話等待。
- 檢查alert.log日誌文件切換的時間
- 檢查awr報告日誌切換的平均時間
示例：在上面的例子中基於 AWR 中的信息，每小時有 29.98 次重做日誌切換：每 2 分鐘切換一次。這個比每 15-20 分鐘切換一次的建議值要高,並將影響前臺進程需要等待'log file sync'完成的時間，因爲發起同步操作的開銷比必要的多。
建議：
- 增加redo logs的大小
3、應用程序提交過多
在這種情況下，要回答的問題是“是否應用程序 commit 過於頻繁？ ”。
如果是，那麼過多的 commit 活動可能會導致性能問題，因爲把 redo 從日誌緩衝區刷新到重做日誌可能會導致等待'log file sync'。
如果’log file sync’的平均等待時間比’log file parallel write’高很多，這意味着大部分時間等待不是由於等待 redo 的寫入，因而問題的原因不是 IO 慢導致。 剩餘時間是 CPU 活動，而且是過多的 commit 導致的最常見的競爭。
此外，如果'log file sync'的平均等待時間低，但等待次數高，那麼應用程序可能 commit 過於頻繁。
比較user commit/rollback同user calls比值的平均值
在 AWR 或 Statspack 報告中，如果每次 commit/rollback 的平均 user calls（"user calls/(user commits+user
rollbacks)"） 小於 30， 表明 commit 過於頻繁
在上面的例子中，我們看到，平均每 5.76 次 user calls 就會有一次 commit, 大約高出建議值 5 倍。基於經驗，我們期望user calls/user commit 至少是 25。當然，這取決於應用程序設計。
建議：
- 如果有很多短事務，看是否可能把這些事務組合在一起，從而減少 commit 操作。 因爲每一個 commit 都必須收到相關 REDO 已寫到磁盤上的確認，額外的 commit 會顯著的增加開銷。雖然 Oracle 可以將某些 commit 組合在一起，通過事務的批處理來減少commit的總體數量還是可以帶來非常有益的效果。
- 看看是否有操作可以使用 COMMIT NOWAIT 選項 （務必在使用前應明白語義）。
- 看看是否有操作可以安全地使用 NOLOGGING/ UNRECOVERABLE 選項完成。
4、其他可能導致log file sync 的等待事件
檢查 AWR 報告，看是否有跟 LGWR 相關的,顯示佔用了顯著數量時間的其他事件,因爲這可能會給出導致這個問題的一個線索。前臺和後臺事件都應該進行檢查。
例如下面的 AWR 顯示某些其他前臺和後臺等待事件等待高，意味着傳輸重做日誌到遠程位置的問題，這可能會導致 foregorund 進程等待"log file sync"。
