這裡先引用一下tanel poder大師的圖：
我們一起來看下面幾個關于log file sync等待事件的問題，歡迎大家一起來揭秘，互相學習，共同進步，徹底搞懂redo的機制。。。
讨論主題：
1、log file sync的原兇到底是什麼？
2、log file sync平均等待事件時間到7毫秒算正常情況？評估log file sync等待事件的名額是什麼？
3、log file sync等待事件與log file parallel write等待事件之間有什麼關系？（下面的圖來自于awr報告中的等待事件，有沒有發現什麼？）
4、log file sync等待會導緻buffer busy waits等待嗎？
5、在實際的項目中碰到了大量的log file sync等待事件，如何優化呢？
yixin0358
頻繁commit/rollback或磁盤I/O有問題，大量實體讀寫争用
westzq1984
對于OLTP，還算正常。但是對于批量處理，有點慢
名額是平均等待時間，以及AWR後續的Wait Event Histogram
vage
3、log file sync等待事件與log file parallel write等待事件之間有什麼關系？（下面的圖來自于awr報告中的等待事件，有沒
有發現什麼？）
log file sync和log file parallel write相差很大，但CPU使用率也不高，這種情況比較少見，這就屬于疑難雜症範疇了。I/O也
很快，CPU也充足，log fie parallel write響應時間很短，但log file sync響應時間确很大。這是最難定位的情況，可以全面對
比下Redo相關資料(v$sysstat中的資料）、Redo相關Latch的變化情況。
比如，redo synch time的平均響應時間，不是每次redo synch time都有送出，但每次送出必有redo synch time。如果redo
synch time向應快，而log file sync慢，則說明Lgwr和程序的互相通知階段出了問題。還有redo entries，這個Redo條目數，真
正含意是程序向Log Buffer中寫Redo的次數。redo log space wait time、redo log space requests資料和Log Buffer Space等
待事件也要關注下。Log Buffer的大小通常不會影響Log File Sync，但通過Log Buffer的變化，可以了解Redo量的變化。
關于Log Buffer對Log File Sync的影響，
在新IMU機制下，Redo資料先在共享池中，送出時傳到Log Buffer中，如果這時有等待，等待時間是Log Buffer Space。從Log
Buffer到磁盤，等待事件才是log file sync。
老機制下也一樣，Log Buffer之前的等待是log buffer space，log buffer之後的等待才是log file sync。
mlx_861201
4、log file sync等待會導緻buffer busy waits等待嗎?
我覺得還是有可能的，我假設一種情況，一個大事務commit，采用的是延遲送出，一個程序要讀取延遲送出的塊，需要修改資料
塊事務槽送出和鎖定狀态，資料行的鎖定狀态，這個過程需要産生redo日志，假設此時log file sync 等待，同時另一個程序讀取
同一個資料塊，就産生了buffer busy waits等待事件，是以log file sync等待會導緻buffer busy waits。
該解答未進過實驗驗證，隻是一個假設，不是真理。
白鳝
一、log file sync平均等待事件時間超過7ms，如果等待時間過長，說明log write每次寫入的時間過長，如果能夠優化redo日志檔案存儲，使之存放在更快的磁盤上，就可以減少這個等待事件的單次等待時間。（RAID 5--> RAID 10）
當無法通過優化redo日志的I/O性能來解決問題，或者優化了redo日志的I/O性能後還是無法達到我們的預期，那麼該如何處理呢？
二、 有經驗的DBA可能會建議加大日志緩沖區（log buffer）。提到加大日志緩沖區，可能有些朋友就會感到疑惑，redo日志檔案寫等待時間長怎麼會和日志緩存沖區直接關聯起來呢？實際上這個問題解釋起來一點也不難，如果資料檔案的I/O性能有問題，平均單塊讀的等待時間偏長，那麼通過加大db cache來減少I/O總次數，進而達到優化I/O的效果。加大日志緩存區的原理也是一樣的，這樣可以使
日志緩存中的存儲更多的redo日志資料，進而減少由于redo日志緩存區不足而産生lgwr寫操作的數量，使平均每次寫入redo日志檔案 的redo位元組數增加，進而減少redo的I/O次數，進而達到優化log file sync等待事件的目的。
三、如果上述兩種方法都不行時，還有一種方法：就是減少送出的次數。如果送出過于頻繁，那麼無論怎麼優化都無法徹底解決問題。
通過加大一次送出記錄的數量，減少送出批次，可以有效地減少log file sync等待時間。采用此方法就意味着需要對應進行較大的調整，甚至要對應用架構做出修改，這種修改的代價将十分巨大。
四、還有一個方案可以優化log file sync事件，就是把部分經常送出的事務設定為異步送出。
異步送出是10g版本引入的新特性，通過設定commit_write參數，可以控制異步送出。
commit_write參數預設值是“immediate,wait”
可以設定為“immediate,nowait”來實作異步送出。
采用異步送出的系統需要做一些額外的校驗和處理，清理不一緻的資料，重新插入剛才由于異步送出而丢失的資料。這就需要在應用層面進行一些特殊處理，建校驗機制和錯誤資料處理機制。我們需要在應用層面進行一些特殊的設定。應該注意的是，那些特别重要的，後續無法重新完全補充的資料不适合使用這種方法 log file sync等待事件是十分關鍵的，我們在資料庫的日常維護中應該對此名額建立基線，如果這個名額有異常變化，一定要盡快分析并解決問題。一旦這個名額惡化，可能導緻系統性能急劇下降，甚至會導緻短暫的挂起。去年，一個客戶的系統，平時log file sync的名額是2-3ms。在一次巡檢時老白發現該名額增長到了7ms, 當時巡檢報告中建議客戶關注這個名額，并盡快檢查存儲系統和作業系統，查出變慢的原因。客戶檢查了存儲，沒發現故障，于是就不了了之了。在下個月巡檢的時候，發現該名額增長到了13ms,再次預警，依然沒有發現問題。随後兩個月這個名額一直持續惡化，增長到了20多毫秒。由于前面幾個月的檢查工作沒有發現問題，而目前系統也還是很正常的，是以客戶也沒有再去認真核查。終于有一天，系統突然挂起，５分鐘後才恢複正常。後來檢查原因，就是log file sync等待導緻。根據我的建議，客戶從頭到尾檢查了一遍，最終發現LVM的一條鍊路存存閃斷現象，修複了鍊路後，一切都恢複正常了。
通過上面的案例，我們要吸取教訓，如果log file sync名額有所惡化，一定要盡快排查問題的根源，如果log file sync的等待時間持續上升，那麼系統出現挂起的可能性也在增加。盡快找到問題的原因是勢在必行的。
5、最後我總結了大家對log file sync等待事件的優化方案：
（1）優化了redo日志的I/O性能，盡量使用快速磁盤，不要把redo log file存放在raid 5的磁盤上；
（2）加大日志緩沖區(log buffer)；
（3）使用批量送出，減少送出的次數；
（4）部分經常送出的事務設定為異步送出；
（5）适當使用NOLOGGING/UNRECOVERABLE等選項；
（6）采用專用網絡，正确設定網絡UDP buffer參數；
（7）安裝最新版本資料庫避免bug，具體bug修複的版本參考文檔；