原貼地址：http://www.itpub.net/thread-1777234-1-1.html 謝謝
這里先引用一下tanel poder大師的圖：
什么是log file sync等待事件呢？在一個提交（commit）十分頻繁的數據庫中，一般會出現log file sync等待事件，當這個等待事件出現在top5中，這個時侯我們需要針對log file sync等待事件進行優化，一定要盡快分析並解決問題，否則當log file sync等待時間從幾毫秒直接到20幾毫秒可能導致系統性能急劇下降，甚至會導致短暫的掛起。
我們一起來看下面幾個關於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等待事件，如何優化呢？
討論時間：2013.4.1--2013.4.16
活動獎勵：活動接受后將會抽取三位會員贈送《Oracle DBA手記3 --數據庫性能優化與內部原理解析》一本。
感謝vage 、 htyansp 、coloredice、yixin0358、westzq1984、yangfeng40 、MyDBNews、mlx_861201、zhouyf605_cu、nannan5000介紹了log file sync的等待事件。
這里特別感謝vage大師，總結的非常徹底！
本次活動中獎者是：westzq1984、mlx_861201、yixin0358
非常感謝大家的積極參與，下面我挑出比較精彩的部分：
yixin0358
1、log file sync的原凶到底是什么？
頻繁commit/rollback或磁盤I/O有問題，大量物理讀寫爭用
westzq1984
2、log file sync平均等待事件時間到7毫秒算正常情況？評估log file sync等待事件的指標是什么？
對於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。
該解答未進過實驗驗證，只是一個假設，不是真理。
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修復的版本參考文檔；
來自白大師（白鱔）對log file sync等待事件優化的總結，供各位puber們學習參考：
一、 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的等待時間持續上升，那么系統出現掛起的可能性也在增加。盡快找到問題的原因是勢在必行的。
來自蓋大師（eygle）對log file sync等待事件優化的總結，供各位puber們學習參考：
http://www.eygle.com/statspack/statspack14-LogFileSync.htm
當一個用戶提交(commits)或者回滾(rollback),session的redo信息需要寫出到redo logfile中.
用戶進程將通知LGWR執行寫出操作,LGWR完成任務以后會通知用戶進程.
這個等待事件就是指用戶進程等待LGWR的寫完成通知.
對於回滾操作，該事件記錄從用戶發出rollback命令到回滾完成的時間.
如果該等待過多，可能說明LGWR的寫出效率低下，或者系統提交過於頻繁.
針對該問題，可以關注:
log file parallel write等待事件
user commits,user rollback等統計信息可以用於觀察提交或回滾次數
解決方案:
1.提高LGWR性能
盡量使用快速磁盤，不要把redo log file存放在raid 5的磁盤上
2.使用批量提交
3.適當使用NOLOGGING/UNRECOVERABLE等選項
可以通過如下公式計算平均redo寫大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
如果系統產生redo很多，而每次寫的較少，一般說明LGWR被過於頻繁的激活了.
可能導致過多的redo相關latch的競爭,而且Oracle可能無法有效的使用piggyback的功能.
我們從一個statspack中提取一些數據來研究一下這個問題.
我們看到，這里log file sync和db file parallel write等待同時出現了.
顯然log file sync在等待db file parallel write的完成.
這里磁盤IO肯定存在了瓶頸，實際用戶的redo和數據文件同時存放在Raid的磁盤上，存在性能問題.
需要調整.
由於過渡頻繁的提交，LGWR過度頻繁的激活，我們看到這里出現了redo writing的latch競爭.
關於redo writing競爭你可以在steve的站點找到詳細的介紹:
http://www.ixora.com.au/notes/lgwr_latching.htm
Oracle Internals Notes
LGWR Latching
When LGWR wakes up, it first takes the redo writing latch to update the SGA variable that shows whether it is active. This prevents other Oracle processes from posting LGWR needlessly. LGWR then takes the redo allocation latch to determine how much redo might be available to write (subject to the release of the redo copy latches). If none, it takes the redo writing latch again to record that it is no longer active, before starting another rdbms ipc message wait.
If there is redo to write, LGWR then inspects the latch recovery areas for the redo copy latches (without taking the latches) to determine whether there are any incomplete copies into the log buffer. For incomplete copies above the sync RBA, LGWR just defers the writing of that block and subsequent log buffer blocks. For incomplete copies below the sync RBA, LGWR sleeps on a LGWR wait for redo copy wait event, and is posted when the required copy latches have been released. The time taken by LGWR to take the redo writing and redo allocation latches and to wait for the redo copy latches is accumulated in the redo writer latching time statistic.
(Prior to release 8i, foreground processes held the redo copy latches more briefly because they did not retain them for the application of the change vectors. Therefore, LGWR would instead attempt to assure itself that there were no ongoing copies into the log buffer by taking all the redo copy latches.)
After each redo write has completed, LGWR takes the redo allocation latch again in order to update the SGA variable containing the base disk block for the log buffer. This effectively frees the log buffer blocks that have just been written, so that they may be reused.
