"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寫的用時。