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報告發現，果真如此！

解決方案：

一、修改Oracle隱含參數

二、打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