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