问题现象：
项目反馈系统反应非常缓慢，数据库服务器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://prefectliu.blog.163.com/blog/static/2363081820123652347371/
http://www.eygle.com/archives/2015/06/sql_version_count.html