您好,登录后才能下订单哦!
这篇文章将为大家详细讲解有关Oracle 11g 遇到log file sync严重等待事件该怎么办,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
数据库版本: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严重等待事件该怎么办就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。