"log file sync"等待事件-2

“log file sync”有三個引數：

P1 = buffer#

P2 = 未使用

P3 = 未使用

buffer#

這個buffer編號(在日誌緩衝區中)的所有改變必須重新整理到磁碟，寫操作的完成保證了交易COMMIT的執行，即使例項crash也會保證COMMIT。因此LGWR的等待就是重新整理這個buffer#。

等待時間：

這種等待完全依賴於LGWR寫出所有必要的redo塊，確保完成後返回給使用者session。等待時間包括了日誌緩衝寫操作和提交操作。等待的時候，每秒都會增加序列號。

查詢阻塞的塊：

如果一個session持續等待同一個buffer#，那麼SEQ#列應該每秒都會增加。否則本地session會出現等待事件超時的問題。如果SEQ#列持續增長，那麼阻塞程式就是LGWR程式。檢查LGWR正在等待哪些日誌塊的完成因而速度緩慢。

系統級等待：

系統級”log file sync“的等待引數顯示了等待COMMIT完成花費的時間。如果這種等待非常明顯，那麼LGWR快速完整地刷出redo的能力就會有問題。”user commits“統計資料顯示COMMIT的次數。

降低等待時間：

為了降低“log file sync”的等待，有幾種常用調優的技巧：

>調優LGWR以能滿足重新整理到磁碟的良好效能，例如不用將redo日誌儲存到RAID5。

>如果有許多短時間的交易，看看是否可以進行批量交易，這樣可以有更少的COMMIT操作。每次COMMIT都需要確認相關的redo資訊是否重新整理到磁碟。儘管commit是由Oracle內部處理的，但是通過批量交易可以降低commit的總體次數，達到一個非常好的效果。

>是否處理能夠使用COMMIT NOWAIT選項(但在使用前需要理解他的語意)。

>確認任何交易使用NOLOGGING/UNRECOVERABLE選項是否安全。

>確認redo日誌是否足夠大。擴大redo日誌，以保證日誌切換可以控制在15到20分鐘之間。

對於降低LOG FILE SYNC等待時間更加詳細的分析可以參考如下：

LOG FILE SYNC等待的總時間可能會被切分為若干子節或元件。

如果確保上面提到的一些調優技巧已經使用了但你的系統仍舊顯示較高的“log file sync”等待時間，那麼你應該將總等待時間切分為單個的元件，然後調優這些元件，組成一個最長用時。

log file sync等待可能被切分為以下元件：

1. 喚醒已停止工作的LGWR。

2. LGWR收集需要寫入磁碟與返回的IO。

3. 日誌寫IO完成的時間。

4. LGWR提交處理IO。

5. 寫操作完成後LGWR提交給前臺/使用者session。

6. 喚醒前臺/使用者session。

基於log file sync切分後的元件的一些調優建議：

2和3累積在"redo write time"統計資訊中。(例如Statspack和AWR的統計資訊節中)

3是“log file parallel write”等待事件。

5和6隨著系統負載的增加可能變得非常明顯。這是因為即使已經返回請求到前臺程式，仍可能需要花費OS時間進行排程執行。需要從作業系統級別的監控。

Data Guard的觀點：

對於Data Guard，具有非同步傳輸與預設的COMMIT WAIT功能，以上的調優步驟仍可以使用，除了第三步也包括對於備機redo日誌的網路寫與RFS/redo寫的用時。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-774624/，如需轉載，請註明出處，否則將追究法律責任。