本文将详细解释当Oracle 11g遇到日志文件同步严重等待事件时该怎么办。文章内容质量较高，边肖将分享给大家参考。希望你看完这篇文章后有所了解。
数据库版本：11.2.0.3.0
RAC两个节点，DG一个节点。
RAC节点1正常，RAC节点2出现日志文件同步严重等待事件，严重影响数据库性能。
根据AWR的报告：
数据库时间过高，日志文件同步等待严重。
在正常情况下，日志文件同步的平均等待时间应为1。
问题是日志缓冲区写入日志文件的速度很慢。
IO问题被排除。
有一篇关于11.2.0.3日志文件同步等待事件的文章。
http://www . askmaclean.com/archives/bug-13551402-high-log-file-syncs-升级后-从-10-2-0-5到-11-2.html
如果您在从10.2.0.5升级到11.2时遇到LOG FILE SYNCS等待事件显著增加的性能问题，那么有必要阅读这篇文章。
在过去的经验中，如果遇到这种情况，应该优先设置“_ use _ adaptive _ log _ file _ sync”=false。自适应日志文件同步是11.2中提出的优化重做日志写入的新功能，在11.2.0.3之后默认为真。
有一种情况，在“_ use _ adaptive _ log _ file _ sync”=false后，日志文件同步等待事件的平均等待时间从10ms缩短到1~2ms。
_use_adaptive_log_file_sync可能会导致性能下降。这可能会导致LGWR使用轮询而不是post/wait，轮询间隔是10ms，这在代码中被写死了。
此外，如果您使用Veritas/symantec ODM，则应特别注意：在使用VERITAS/Symantec ODM升级11.2之后，您可能会遇到BUG 13551402高“日志文件并行写入”和“日志文件同步”的情况，该问题已被确认存在于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
-
_使用_自适应_日志_文件_同步
错误的
自适应地在开机自检/等待和轮询之间切换
换了AWR再跑。
通过比较两天前和两天后同一时间的AWR报告，日志文件同步等待事件消失。文件同步变为1。
时间也大幅下降。
解决问题。
我将在这里分享当Oracle 11g遇到日志文件同步严重等待事件时该怎么办。我希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/127541.html