值班电话铃声响起，把正要下班的我又拉回了工作状态，迅速拿起电话，查看短信，短信显示19点XX系统出现大量大量“cursor Mutex X”等待事件，迅速放下电脑包，掏出电脑，连上系统查看，整个过程90秒内一气呵成，这些年良好的战斗意识及年复一年，日复一年的实战淬炼，让自己各方面的速度，都有了长足的进步。
显示数据库解析时间较长，硬解析占解析总时间小
数据库cursor Mutex X占总等待的64.2%。
进一步分析，从Mutex Sleep Summary显示，耗时发生在增加子游标时，增加子游标需要对父游标加独占锁。Cursor Mutex X主要作用对于父游标的操作，增加子游标虽然更高效，但一个父游标下不宜增加太多的子游标，因为子游标会对父游标产生独占锁。此次问题出现909个子游标，所以重点排查为什么出现子游标，且子游标没有被共享的原因。
通过上图查询反馈可知大量子游标没被共享，是由三个导致：
1） BIND_MISMATCH
2） PURGED_CURSOR
3）BIND_LENGTH_UPGRADEABLE
第一个原因表示绑定变量类型不一致（例如：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技术更迭，更多有意思的技术需要我们去学习。
京公网安备 11010802041100号