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