Oracle触发bug(cursor: mutex S)，造成数据库服务器CPU接近100%---SQL子游标多版本问题

问题现象：

项目反馈系统反应非常缓慢，数据库服务器CPU接近100%！

INSERT INTO GSPAudit1712(ID,TypeID,CategoryID,DateTime,UserID,UserCode,UserName,UserEmail,PositionID,PositionCode,PositionName,EventID,EventName,EventResult,FunctionID,FunctionCode,FunctionName,IP,OrganizationID,OrganizationCode,OrganizationName,Description,DataAccess,DataKey) 

values(:id,:typeid,:CategoryID,:datetime,:UserID,:UserCode,:UserName,:UserEmail,:PositionID,:PositionCode,:PositionName,:EventID,:EventName,:EventResult,:FunctionID,:FunctionCode,:FunctionName,:IP,:OrganizationID,:OrganizationCode,:OrganizationName,:Description,:DataAccess,:DataKey)

 

分析过程：

收到反馈的CPU消耗较高如下SQL后，感觉很奇怪：这是产品中一个很简单的日志插入SQL，项目的规模也不是很大，怎么会产生CPU瓶颈呢？

联系现场部署DBSQLMonitor监控所有会话的状态和等待事件： http://www.cnblogs.com/zhaoguan_wang/p/5316828.html

确实有大量活动会话，等待的是比较少见的：cursor: mutex S、kksfbc child completion、library cache lock

搜索了对应的关键字发现，很可能是触发了Oracle的bug：10636231，典型特征为参数化的SQL不停的硬解析而没有共享。

检查对应时间段的awr报告发现，果然如此！

解决方案：

1、修改Oracle隐含参数

2、打Oracle补丁或升级Oracle版本（11.2.0.4+）   ---现在发现Oracle 12.2中仍然存在此问题 2018.05.31

版本11.1.0.7
SQL> alter system set "_cursor_features_enabled"=18 scope=spfile;
System altered.
SQL> alter system set event='106001 trace name context forever,level 1024' scope=spfile;
System altered.
并重启实例

版本11.2.0.1
SQL> alter system set "_cursor_features_enabled"=34 scope=spfile;
System altered.
SQL> alter system set event='106001 trace name context forever,level 1024' scope=spfile;
System altered.

版本11.2.0.2
SQL> alter system set "_cursor_features_enabled"=1026 scope=spfile;
System altered.
SQL> alter system set event='106001 trace name context forever,level 1024' scope=spfile;
System altered.

版本11.2.0.3+
alter system set "_cursor_obsolete_threshold"=1024 scope=spfile;

 

参考资料：

  http://www.askmaclean.com/archives/11-2-obsolete-parent-cursors-_cursor_features_enabled-106001-event.html

  http://prefectliu.blog.163.com/blog/static/2363081820123652347371/

  http://www.eygle.com/archives/2015/06/sql_version_count.html