ORACLE AWR報告之 log file sync等待事件優化的總結【轉自ITPUB】

來自白大師（白鱔）對log file sync等待事件優化的總結，供各位puber們學習參考：

1、 　log file sync平均等待事件時間超過7ms，若是等待時間過長，說明log write每次寫入的時間過長，若是可以優化redo日誌文件存儲，使之存放在更快的磁盤上，就能夠減小這個等待事件的單次等待時間。（RAID 5--> RAID 10）
  　當沒法經過優化redo日誌的I/O性能來解決問題，或者優化了redo日誌的I/O性能後仍是沒法達到咱們的預期，那麼該如何處理呢？


  2、 有經驗的DBA可能會建議加大日誌緩衝區（log buffer）。提到加大日誌緩衝區，可能有些朋友就會感到疑惑，redo日誌文件寫等待時間長怎麼會和日誌緩存衝區直接關聯起來呢？實際上這個問題解釋 起來一點也不難，若是數據文件的I/O性能有問題，平均單塊讀的等待時間偏長，那麼經過加大db cache來減小I/O總次數，從而達到優化I/O的效果。加大日誌緩存區的原理也是同樣的，這樣可使
    日誌緩存中的存儲更多的redo日誌數據，從而減小因爲redo日誌緩存區不足而產生lgwr寫操做的數量，使平均每次寫入redo日誌文件的redo字節數增長，從而減小redo的I/O次數，進而達到優化log file sync等待事件的目的。


　3、若是上述兩種方法都不行時，還有一種方法：就是減小提交的次數。若是提交過於頻繁，那麼不管怎麼優化都沒法完全解決問題。
　經過加大一次提交記錄的數量，減小提交批次，能夠有效地減小log file sync等待時間。採用此方法就意味着須要對應進行較大的調整，甚至要對應用架構作出修改，這種修改的代價將十分巨大。
　　
　4、還有一個方案能夠優化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們學習參考：


一、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緩慢，拖慢了提交的過程。

二、 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競爭一些會加巨的。

三、 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。

四、控制文件I/O有可能影響log file sync。
此問題還沒來得及深刻研究，只是之前在阿里的數據庫中觀察到這一現象。

五、Log File Sycn和Buffer Busy Waits。
沒 有直接關係。是其餘緣由，好比Redo相關的Latch，致使了Log File Sync和Buffer Busy Waits同時出現。此時Log File Sync和Buffer Busy Waits都不是原兇，真正的原兇是Log Buffer訪問性能降低。

六、以同步模式向遠端DataGuard傳送Redo，也會致使Log File Sync。

Redo是Oracle重要的優化對象，DBWR的工做原理我已經破譯的差很少了，下一目標就是LGWR，惋惜還沒來得及搞，之後有時間再爲你們詳細總結。