共計 1799 個字符,預計需要花費 5 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關 Oracle 11g 遇到 log file sync 嚴重等待事件該怎么辦,文章內容質量較高,因此丸趣 TV 小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
數據庫版本:11.2.0.3.0
RAC 雙節點,DG 一節點。
RAC 節點 1 正常,RAC 節點 2 出現 log file sync 嚴重等待事件,數據庫性能受到嚴重影響。
從 AWR 報告看:
DB Time 很高,log file sync 等待嚴重。
正常情況下 log file sync 的 Avg wait 應該是 1。
問題表現是 log buffer 向 log file 寫入很慢。
排除了 IO 問題。
有一篇文章關于 11.2.0.3 的 log file sync 等待事件問題。
http://www.askmaclean.com/archives/bug-13551402-high-log-file-syncs-after-upgrading-from-10-2-0-5-to-11-2.html
如果 你遇到從 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 平臺上提供補丁:
這里我直接修改“_use_adaptive_log_file_sync”=false
ALTER SYSTEM SET _use_adaptive_log_file_sync =FALSE;
SQL SELECT ksppinm, ksppstvl, ksppdesc
2 FROM x$ksppi x, x$ksppcv y
3 WHERE x.indx = y.indx AND ksppinm like _use_adaptive_log_file_sync
KSPPINM
——————————————————————————–
KSPPSTVL
——————————————————————————–
KSPPDESC
——————————————————————————–
_use_adaptive_log_file_sync
FALSE
Adaptively switch between post/wait and polling
改完后再跑一下 AWR。
通過前后兩天同一時間的 AWR 報告做對比,log file sync 等待事件消失。log file sync 變成了 1。
DB Time 也大幅下降。
問題解決。
關于 Oracle 11g 遇到 log file sync 嚴重等待事件該怎么辦就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。