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"
Error message: Linux-x86_64 Error: 23: Too many open files in system

检查数据库服务器的配置，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等待事件。

定位是否是原因1的问题，就找Segments by Global Cache Buffer Busy。然后根据对象的名称去找对应的SQL，然后查看SQL的执行计划定位问题。

Segments by Global Cache Buffer Busy

• % of Capture shows % of GC Buffer Busy for each top segment compared
• with GC Buffer Busy for all segments captured by the Snapshot

定位是否是问题2造成，先查看数据库IO的整体情况，如果是RAC，多个节点都要看，因为RAC是共享存储，消耗IO总量是多个节点之和。如果如下图所示，相比数据库正常的时刻是非常大的。

如何判断是否是问题2影响了问题1，就查看问题1找到的SQL是否有消耗IO，如果有，则有影响。

IOStat by Function summary

• 'Data' columns suffixed with M,G,T,P are in multiples of 1024 other columns suffixed with K,M,P are in multiples of 1000
• ordered by (Data Read + Write) desc

问题2的定位是通过segments by physical reads来找到相应的SQL。

Segments by Physical Reads

• Total Physical Reads: 67,312,485
• Captured Segments account for 81.6% of Total