故障类型

rdbms ipc reply 等待严重，数据库整体性能下降

现象错误号

2013 年 2 月 2 号 12:40 至 13:00 ，客户前台业务操作比较缓慢。 数据库 1 号节点 CPU 资源比较紧张，使用率在 90% 以上，同时 1 号节点也出现了比较多的 rdbms ipc reply 等待事件。

故障描述

          对 客户 业务系统运行进行综合判断之后，基本确认为在混合批处理环境下的业务高并发导致，业务运行是相对缓慢而不是无法继续。在无法确认应用是否变化的前提下，基本可以排除应用程序原因。综合来看，导致本次业务运行缓慢的主要原因有以下几点：

l   1 号节点 CPU 负载过高，使用率达到了 95% 左右。

l   1 号节点高并发环境的软解析指标过高，每秒钟达到了 8500 次左右，而 2 号节点每秒钟只有 2300 次左右，负载不均衡。

l   软解析过高导致 RAC 后台进程 lck 压力过大。 lck 进程主要用于传递 library cache 和 row cache 之间的资源。而 CPU 负载过高又会导致 lck 进程无法获得 CPU 时间片，进而导致 lck 出现等待。

l   Bug 10314582 。该 BUG 在 Oracle 11.2.0.3 修复。        

2013 年 2 月 2 日 13 点左右 客户 数据库 1 号节点主机 CPU 资源比较紧张，使用率高达 95% 以上，如下所示：

同时 1 号节点出现了如下等待事件，其中 rdbms ipc reply 等待事件居于首位，每次等待时间高达 118ms ，如下所示：

进一步通过查看 ASH 报告，发现该等待事件主要由 lck 进程引起， 44 号表示 lck 进程 , 如下所示：

等待 rdbms ipc reply 的 SQL 语句为 ggw0k4vu2q9yc ：

该 SQL 语句执行频率非常之高，每秒钟高达 183 次：

lck 进程的主要作用是协调非 Cache Fusion 资源（ Cache Fusion 资源主要指的是数据块，由 lms 进程负责传输），如协调 library cache 和 row cache 中的资源。当系统的 CPU 资源比较紧张的时候， lck 进程可能会由于获得不了 CPU 时间片，而导致协调资源效率低下。而故障期间 1 号节点的软解析次数高达 8382 次，进一步加剧了 lck 进程的繁忙程度，如下所示：

根据客户反馈，故障期间 lck 进程主要等待 css group membership query 等待事件，该等待事件就是协调节点间的资源。

查询 MOS ，发现类似 BUG ，该 BUG 在 11.2.0.3 中已经修复， MOS DOC ID 如下所示：

Bug 10314582 - "rdbms ipc reply" waits when parsing in RAC (Doc ID 10314582.8)

故障总结建议

（ 1 ）、增加 SESSION_CACHED_CURSORS 的值来缓解一下软解析高的问题，目前改值为 300 ，调整到 500 。

（ 2 ）、确认 sqlid 为 ggw0k4vu2q9yc 执行如此频繁的原因，降低 CPU 消耗。

（ 3 ）、确认双节点业务负载不均衡原因， 1 号节点软解析高达 8500 左右，而二号节点只有 2500 左右。

（ 3 ）、 CRM 升级至 11.2.0.3.5 。