2017-03-27Oracle故障gc buffer busy acquire导致数据库不可用
实施反馈系统有20分钟不可用,然后又自动恢复了。先查看alert日志,看到打开文件数不够,系统已经运行几年了,怎么可能呢。 Non critical error ORA-48180 caught while writing to trace file "/u01/app/ora/diag/rdbms/nwzcdb/nwzcdb2/trace/nwzcdb2_ora_195339.trc" 检查数据库服务器的配置,ulimit -a ,发现oracle hard nofile 65536,应该是足够大的。 查看问题时段的数据库报告,发现数据库过载了。 11g开始gc buffer busy分为gc buffer busy acquire和gc buffer busy release: gc buffer busy acquire是当session#1尝试请求访问远程实例(remote instance) buffer,但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy acquire。 gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy release。 我认为可能是两个原因造成的: 1. 低效SQL,逻辑读过大,且访问频繁,造成争用严重。 2. 数据库IO资源紧张,导致一些频繁访问的SQL语句响应慢,造成gc buffer busy acquire,gc buffer busy release等待事件。 Segments by Global Cache Buffer Busy
定位是否是问题2造成,先查看数据库IO的整体情况,如果是RAC,多个节点都要看,因为RAC是共享存储,消耗IO总量是多个节点之和。如果如下图所示,相比数据库正常的时刻是非常大的。 如何判断是否是问题2影响了问题1,就查看问题1找到的SQL是否有消耗IO,如果有,则有影响。 IOStat by Function summary
问题2的定位是通过segments by physical reads来找到相应的SQL。 Segments by Physical Reads
(编辑:鄂州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |