RAC 資料庫中的'log file sync' 等待事件

RAC 資料庫中的'log file sync' 等待事件要比單機資料庫中的'log file sync' 等待事件複雜，主要原因是由於RAC 資料庫需要將SCN同步到所有例項。

首先，回顧一下單機資料庫中的'log file sync' 等待事件，當user session 提交（commit）時，user session會通知LGWR程式將redo buffer中的資訊寫入到redo log file，當LGWR程式完成寫操作後，LGWR再post（通知）user session 寫操作已經完成，user session 接收到LGWR的通知後提交操作才完成。因此user session 在沒有收到LGWR post（通知）之前一致處於等待狀態，具體的等待事件為'log file sync'。

在RAC資料庫中為了一致性讀，需要將Commit SCN同步/傳播到所有的節點上。SCN同步/傳播的主要方法有兩種：Lamport SCN 和 immediate commit propagation (BOC)。

10gR1 及以下版本預設使用Lamport SCN，Lamport SCN方式即一個節點上的commit SCN 不保證立刻同步/傳播到所有節點，也就是說可能延時同步/傳播，對於一些實時性要求高的RAC資料庫Lamport SCN方式是不可取的。如果希望commit SCN 立刻同步/傳播到所有節點，手動修改引數MAX_COMMIT_PROPAGATION_DELAY=1

從10gR2開始預設使用immediate commit propagation (BOC)，BOC即一個節點上的commit SCN 立刻同步/傳播到所有節點。

介紹 immediate commit propagation (BOC)的工作原理

1. user session 執行提交（commit），user session會通知LGWR程式將redo buffer中的資訊寫入到redo log file。

2. LGWR程式收到user session通知後，將redo buffer中的資訊寫入redo log file，同時LGWR 將COMMIT SCN 同步/傳播給遠端的資料庫例項的LMS 程式。

3. 遠端資料庫例項的LMS將commit SCN同步到本地SCN，然後通知commit例項的LMS，表示SCN 同步已經完成。

4. 當commit 例項的LMS接收到所有遠端資料庫例項的LMS的通知後，commit 例項的LMS再通知本地的LGWR 所有節點SCN同步已經完成。

5. LGWR 在完成了IO 操作和LMS程式通知後，LGWR通知user session commit 成功。user session在沒有收到LGWR通知前，一直處於等待log file sync。

通過以上原理的說明，我們不難看出來導致'log file sync' 等待事件的主要原因有：

1. 磁碟IO 慢導致LGWR程式將redo buffer中的資訊寫入到redo log file速度慢。

2. user session commit過於頻繁。

3. 本地或者遠端伺服器CPU資源不足，導致LMS和/或者LGWR不能及時得到CPU排程，不能正常工作。

4. RAC私有網路效能差，導致LMS同步commit SCN慢。

5. ORACLE BUG.

分析處理'log file sync' 等待事件時的重要log/資訊

1. AWR

例如：AWR中log file sync 的等待時間與log file parallel write的時間基本相同，因此是由於IO問題導致的log file sync.

2. LGWR and LMS process trace file

例如：LGWR trace檔案中報出下面的資訊，很有可能是IO慢導致的。

Warning: log write time 1000ms, size 2KB

3. OSWatcher https://blogs.oracle.com/Database4CN/entry/%E5%88%A9%E5%99%A8osw_oswatcher_black_box_%E4%B9%8B%E7%AE%80%E4%BB%8B%E7%AF%87 4. Alert log

5. Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) [Document 1064487.1]

解決'log file sync' 等待事件主要方法

1. 提高磁碟IO速度

2. 採用批量提交，減少應用commit次數

3. 安裝OSWatcher 定位CPU使用率高的程式 4. 採用專用網路，正確設定網路UDP buffer引數

5. 安裝最新版本資料庫避免bug，具體bug修復的版本參考文件： 

WAITEVENT: "log file sync" Reference Note (Doc ID 34592.1)

如果 你遇到從10.2.0.5升級到11.2出現LOG FILE SYNCS等待事件顯著增長的效能問題，那麼有必要讀一下這篇文章了。
 
在以往的經驗中如果遇到這種場景 ，那麼 優先考慮設定 “_use_adaptive_log_file_sync”=false, adaptive log file sync是 11.2中提出的一個優化重做日誌寫的新特性， 在11.2.0.3以後預設為TRUE。
有客戶在將”_use_adaptive_log_file_sync”=false後，log file sync等待事件的平均等待時間從10ms 下降到 1~2ms的案例。
 
_use_adaptive_log_file_sync造成效能下降的原因可能是其導致LGWR使用了polling 方式來取代 post/wait，並且polling的間隔是10ms，這個間隔是在程式碼裡寫死的。
 
此外如果使用了Veritas/symantec 的ODM的話也需要特別注意：你可能遇到了Bug 13551402  High “log file parallel write” and “log file sync” after upgrading 11.2 with Veritas/Symantec ODM，這個BUG已經確認在11.2.0.3和11.2.0.2上存在。
對於該bug的內部討論最後確認是由於 11.2中lgwr的 IO使用了一種批量同步I/O介面，導致當配合Veritas/symantec 的ODM一起使用時會導致效能下降。
目前該BUG已經在多個Unix/Linux平臺上提供補丁：

 

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