顯示數(shù)據(jù)庫解析時間較長，硬解析占解析總時間小

數(shù)據(jù)庫cursor Mutex X占總等待的64.2%。

進一步分析，從Mutex Sleep Summary顯示，耗時發(fā)生在增加子游標時，增加子游標需要對父游標加獨占鎖。Cursor Mutex X主要作用對于父游標的操作，增加子游標雖然更高效，但一個父游標下不宜增加太多的子游標，因為子游標會對父游標產生獨占鎖。此次問題出現(xiàn)909個子游標，所以重點排查為什么出現(xiàn)子游標，且子游標沒有被共享的原因。

通過上圖查詢反饋可知大量子游標沒被共享，是由三個導致：

第一個原因表示綁定變量類型不一致（例如：varchar2類型和char類型）

第二個原因表示子游標被標記為清除狀態(tài)

第三個原因表示綁定變量類型的長度發(fā)生了變化（例如：char(10)和char(20)）

sql_id=acd564w6af7t6語句的綁定變量類型及表字段數(shù)據(jù)類型對比

左邊為綁定變量的數(shù)據(jù)類型，右邊為對應表字段數(shù)據(jù)類型，通過對比發(fā)現(xiàn)，幾乎沒有完全與之匹配的數(shù)據(jù)類型，也驗證了子游標沒有被共享的原因：綁定變量類型和綁定變量類型的長度發(fā)生了變化。

綜上所述可得出結論，產生cursor Mutex X的原因是insert into..values..語句中元數(shù)據(jù)的綁定變量類型和長度不一致，使得子游標沒有被共享。

電話應用側幫忙核實綁定變量數(shù)據(jù)類型與元數(shù)據(jù)類型，使其類型一致。另外：參考mos (2625815.1)顯示由Oracle 11g升級至12c以后的版本也會引起對應bug（bug號28889389，補丁號：28889389）

于是查看數(shù)據(jù)庫補?。?/span>

數(shù)據(jù)庫并未安裝對應補丁，存在觸發(fā)bug隱患，后續(xù)得找窗口實施補丁。

至此戰(zhàn)斗結束，匯報各方，后續(xù)跟緊開發(fā)整改，補丁實施，形成閉環(huán)。我們運維人就是7X24小時的擼命，一個電話，不論你身處何地，無論你在做啥，即便做的是父母期盼的千秋大業(yè)，也得隨時停止投入到問題處理中來，這一點我相信每一個運維人都感同身受吧。所以，加強自愈，加強白屏化操作，才能讓自己從瑣碎的，重復性的工作中抽身出來，一來加強自己父母期待的千秋大業(yè)，二來也有時間讓自己不斷提升，畢竟日新月異的IT技術更迭，更多有意思的技術需要我們去學習。