徹底揭祕log file sync等待事件-轉自itpub

原貼地址：http://www.itpub.net/thread-1777234-1-1.html   謝謝

guoyJoe 老大  

這裏先引用一下tanel poder大師的圖：

　　什麼是log file sync等待事件呢？在一個提交（commit）十分頻繁的數據庫中，通常會出現log file sync等待事件，當這個等待事件出如今top5中，這個時侯咱們須要針對log file sync等待事件進行優化，必定要儘快分析並解決問題，不然當log file sync等待時間從幾毫秒直接到20幾毫秒可能致使系統性能急劇降低，甚至會致使短暫的掛起。

　　咱們一塊兒來看下面幾個關於log file sync等待事件的問題，歡迎你們一塊兒來揭祕，相互學習，共同進步，完全搞懂redo的機制。。。

    　討論主題：

一、log file sync的原兇究竟是什麼？

二、log file sync平均等待事件時間到7毫秒算正常狀況？評估log file sync等待事件的指標是什麼？

三、log file sync等待事件與log file parallel write等待事件之間有什麼關係？（下面的圖來自於awr報告中的等待事件，有沒有發現什麼？）



四、log file sync等待會致使buffer busy waits等待嗎？

五、在實際的項目中碰到了大量的log file sync等待事件，如何優化呢？


討論時間：2013.4.1--2013.4.16


活動獎勵：活動接受後將會抽取三位會員贈送《Oracle DBA手記3 --數據庫性能優化與內部原理解析》一本。


感謝vage 、 htyansp 、coloredice、yixin035八、westzq198四、yangfeng40 、MyDBNews、mlx_86120一、zhouyf605_cu、nannan5000介紹了log file sync的等待事件。
這裏特別感謝vage大師，總結的很是完全！

本次活動中獎者是：westzq198四、mlx_86120一、yixin0358

很是感謝你們的積極參與，下面我挑出比較精彩的部分：

yixin0358
一、log file sync的原兇究竟是什麼？
頻繁commit/rollback或磁盤I/O有問題，大量物理讀寫爭用

westzq1984
二、log file sync平均等待事件時間到7毫秒算正常狀況？評估log file sync等待事件的指標是什麼？
對於OLTP，還算正常。可是對於批量處理，有點慢
指標是平均等待時間，以及AWR後續的Wait Event Histogram

vage
三、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
四、log file sync等待會致使buffer busy waits等待嗎?
  我以爲仍是有可能的，我假設一種狀況，一個大事務commit，採用的是延遲提交，一個進程要讀取延遲提交的塊，須要修改數據
塊事務槽提交和鎖定狀態，數據行的鎖定狀態，這個過程須要產生redo日誌，假設此時log file sync 等待，同時另外一個進程讀取
同一個數據塊，就產生了buffer busy waits等待事件，因此log file sync等待會致使buffer busy waits。
該解答未進過實驗驗證，只是一個假設，不是真理。

五、最後我總結了你們對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們學習參考：

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.