潛水珽的異想世界

oracle的學習過程,會發現其實官方很會在新版本中放入新的功能(也許是先試試水溫),但也因為這樣,引發出後續的一些問題,造成系統的不穩定,接下來,來分享一下一下最近在系統問題處理上困擾很久的狀況。

系統最近不太乖(還特別去檢查了一下乖乖有沒有過期?)常常會遇到像下面這樣commit量衝夭壽高的狀況,所以開始一連串的處理,最後調整了一個隱藏參數,目前持續觀察中。下面就針對log file sync這個等待事件,來做深入的解說,可以做為未來系統診斷除錯的思路。

Lamport SCN vs immediate commit propagation (BOC):
在Oracle RAC數據庫中,為了讀一致性，需要將Commit SCN同步／傳播到所有的節點上。SCN同步／傳播的主要方法有兩種：Lamport SCN 和immediate commit propagation (BOC)。   
10gR1 及以下版本默認使用Lamport SCN，Lamport SCN方式即一個節點上的commit SCN 不保證立刻同步／傳播到所有節點，也就是說可能延時同步／傳播，在RAC節點上，這樣有時候會早成資料讀取不一致的問題，對於一些實時性要求高的RAC數據庫Lamport SCN方式是無法滿足的。                                                                                                                                                        
從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 wait事件。

以上這些過程,亦稱為Post/Wait模式。

從上面的這些描述,我們會發現,其實在RAC的世界中,為了達到每個節點的commit SCN一致性,背後有很多的訊息,時時刻刻的正透過前後台進程在做溝通,當系統很忙碌的情形下,為了在這部分加快速度,oracle 11.2的版本將調整了這些程序的行為模式, 可以通過定時獲取的方式來查詢寫出進度，這被稱為Polling模式。在Oracle 11.2.0.3中，這個特性被默認開啟，通過隱含參數" _use_adaptive_log_file_sync "來控制（默認值為true ），這個參數的含義是：數據庫可以在自動調整的在Post/Wait和Polling模式間選擇和切換，正是由於這個原因，帶來了很多Bug ，反而使得log file sync的等待異常的高(短則幾十秒,長則數十分鐘,但通常為幾分鐘)。因此，如果在Oracle 11.2.0.3版本中觀察到這樣的特徵，那麼就極有可能與此特性的Bug有關。

在Post/Wait和Polling機制之間的切換，Oracle會記錄到LGWR進程的trace當中，如下所示：

Log file sync switching to polling

……

Log file sync switching to post/wait

若遇到此問題，則通常將隱含參數" _use_adaptive_log_file_sync "設置為false ，回歸到以前的Post/Wait模式，這將會有助於問題的解決。關閉Polling模式的命令為：

alter system set "_use_adaptive_log_file_sync"=false sid='*';

通過以上原理的說明，我們不難看出來導致'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.資料庫本身的bug，可以考慮是不是因為自動調整 Post/Wait 與Polling 所引發的bug問題。

參考文件:
Ref: https://blogs.oracle.com/database4cn/post/rac-log-file-sync
Document 1462942.1 Adaptive Switching Between Log Write Methods can Cause 'log file sync' Waits
Document 13707904.8 Bug 13707904 - LGWR sometimes uses polling, sometimes post/wait
Document 13074706.8 Bug 13074706 - Long "log file sync" waits in RAC not correlated with slow writes
Document 25178179.8 Bug 25178179 - Several sessions wait on 'log file sync' in a RAC environment

NOTE:1318709.1 - AIX: Long "log file sync" Wait Time in 11.2. : Things To Check
NOTE:13707904.8 - Bug 13707904 - LGWR sometimes uses polling, sometimes post/wait
NOTE:10318123.8 - Bug 10318123 - Solaris: LGWR regularly stalls for 3 seconds at a time
NOTE:1462942.1 - Adaptive Switching Between Log Write Methods can Cause 'log file sync' Waits
NOTE:13551402.8 - Bug 13551402 - High "log file parallel write" and "log file sync" after upgrading 11.2 with Veritas/Symantec ODM
NOTE:1376916.1 - Troubleshooting: 'Log file sync' Waits
NOTE:13074706.8 - Bug 13074706 - Long "log file sync" waits in RAC not correlated with slow writes