ORACLE AWR報告之 log file sync等待事件優化的總結【轉自ITPUB】
來自白大師（白鱔）對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.
------------------------------------------------------------------------------------
來自呂大師（vage）對log file sync等待事件優化的總結，供各位puber們學習參考：
1、Log File Sync是從提交開始到提交結束的時間。Log File Parallel Write是LGWR開始寫Redo File到Redo File結束的時間。明確了這一點，可以知道，Log file sync 包含了log file parallel write。所以，log file sync等待時間一出，必先看log file parallel write。如果log file sync平均等待時間（也可稱為提交響應時間）為20ms，log file parallel write為19ms，那麼問題就很明顯了，Redo
file I/O緩慢，拖慢了提交的過程。
2、 Log File Sync的時間不止log file parallel write。伺服器程序開始提交，到通知LGWR寫Redo，LGWR寫完Redo通知程序提交完畢，來回通知也是要消耗CPU的。除去來回通知 外，Commit還有增加SCN等等操作，如果log
file sync和log file parallel write差距很大，證明I/O沒有問題，但有可能是CPU資源緊張，導致程序和LGWR來回通知或其他的需要CPU的操作，得不到足夠的CPU，因而產 生延遲。
這 種情況下要看一下CPU的佔用率、Load，如果Load很高、CPU使用率也很高，哪就是由於CPU導致Log file sync響應時間加長。這種情況下，資料庫通常會有一些併發症，比如Latch/Mutex的競爭會比平常嚴重些，因為CPU緊張嗎，Latch
/Mutex競爭一些會加巨的。
3、 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。
4、控制檔案I/O有可能影響log file sync。
此問題還沒來得及深入研究，只是以前在阿里的資料庫中觀察到這一現象。
5、Log File Sycn和Buffer Busy Waits。
沒 有直接關係。是其他原因，比如Redo相關的Latch，導致了Log File Sync和Buffer Busy Waits同時出現。此時Log File Sync和Buffer Busy Waits都不是原凶，真正的原凶是Log Buffer訪問效能下降。
6、以同步模式向遠端DataGuard傳送Redo，也會導致Log File Sync。
Redo是Oracle重要的優化物件，DBWR的工作原理我已經破譯的差不多了，下一目標就是LGWR，可惜還沒來得及搞，以後有時間再為大家詳細總結。