最近某客户现场一套12C的RAC在一天内出现多次librarycache lock，cursor：pinSwait on X，enq：TX-rowlock contention异常等待事件，通过介入针对数据库会话进行kill后，数据库等待事件恢复正常。

详细分析过程如下：

一、通过查看故障时间点awr报告存在sql频繁解析失败，导致大量硬解析

二、通过检查节点1，2都发生过sharepool抖动，另外从故障时间点（22:00-22:53）采集节点2的ADDM报告可以看出主要集中在SharedPool Latches的竞争。

三、在故障发生过程中，发现系统存在自动任务调起的情况(自动统计信息收集，自动分段顾问），因为自动统计信息收集发起导致cursor失效，sql需要重新解析，这也是故障原因之一。

数据库在开启10035后发现后台有未执行成功的SQL。

启用10035事件

Altersystem set events '10035 trace name context forever,level 1';

关闭10035事件

Altersystem set events '10035 trace name context off';

注：

开启10035事件抓取解析失败sql不能作为日常项来开展，此类sql均是因为sql语法错误，访问对象不存在或字段缺失等原因导致，

应用应该上线前应该做好评审把控，做好功能测试（这类报错往往功能测试都是通不过的），将此类问题sql控制在源头，扎好上线的口袋；

长期开启10035事件有以下两点不利因素：

1、数据库开启10035并不是一种日常维护手段。

2、10035事件会将解析失败的语句信息写入数据库alert，易造成错误信息刷屏，增加了数据库目录撑爆的风险,以及日常巡检维护难度。

总结：

首先是应用发起的SQL解析失败及硬解析导致cursor。然后统计信息收集导致部分cursor失效，从而加重了SQL解析压力。sharedpool本来剩余空间就有点不足了，所以压力一来就会grow，但是在dbcache空间不能及时释放出来的，sharedpool grow失败的情况下，更加加重了sharedpool闩锁的竞争。

建议如下：
1、协助应用整改未执行成功sql。

2、目前数据库两个节点sharepool频繁调整，将sharepool size 从10G调整至15G。

3、关闭autospace advisor，sqltuningadvisor(已关闭理赔库该参数)和oracle_ocm相关job及调整autooptimizerstats collection调度时间。