性能故障之cursorMutexX异常等待处理

显示数据库解析时间较长，硬解析占解析总时间小

数据库cursor Mutex X占总等待的64.2%。

进一步分析，从Mutex Sleep Summary显示，耗时发生在增加子游标时，增加子游标需要对父游标加独占锁。Cursor Mutex X主要作用对于父游标的操作，增加子游标虽然更高效，但一个父游标下不宜增加太多的子游标，因为子游标会对父游标产生独占锁。此次问题出现909个子游标，所以重点排查为什么出现子游标，且子游标没有被共享的原因。

通过上图查询反馈可知大量子游标没被共享，是由三个导致：

第一个原因表示绑定变量类型不一致（例如：varchar2类型和char类型）

第二个原因表示子游标被标记为清除状态

第三个原因表示绑定变量类型的长度发生了变化（例如：char(10)和char(20)）

sql_id='acd564w6af7t6'语句的绑定变量类型及表字段数据类型对比

左边为绑定变量的数据类型，右边为对应表字段数据类型，通过对比发现，几乎没有完全与之匹配的数据类型，也验证了子游标没有被共享的原因：绑定变量类型和绑定变量类型的长度发生了变化。

综上所述可得出结论，产生cursor Mutex X的原因是insert into..values..语句中元数据的绑定变量类型和长度不一致，使得子游标没有被共享。

电话应用侧帮忙核实绑定变量数据类型与元数据类型，使其类型一致。另外：参考mos (2625815.1)显示由Oracle 11g升级至12c以后的版本也会引起对应bug（bug号28889389，补丁号：28889389）

于是查看数据库补丁：

数据库并未安装对应补丁，存在触发bug隐患，后续得找窗口实施补丁。

至此战斗结束，汇报各方，后续跟紧开发整改，补丁实施，形成闭环。我们运维人就是7X24小时的撸命，一个电话，不论你身处何地，无论你在做啥，即便做的是父母期盼的千秋大业，也得随时停止投入到问题处理中来，这一点我相信每一个运维人都感同身受吧。所以，加强自愈，加强白屏化操作，才能让自己从琐碎的，重复性的工作中抽身出来，一来加强自己父母期待的千秋大业，二来也有时间让自己不断提升，毕竟日新月异的IT技术更迭，更多有意思的技术需要我们去学习。