共计 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 严重等待事件该怎么办就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。