oracle一次无法登陆案例

故障描述

2023年06月30号，客户应用反馈imagedb数据库无法登录。

原因分析

检查cpu使用正常；内存耗尽只剩余200M左右的空间。
检查会话，大概有800个左右的会话，如下图所示：

检查执行计划：

经过检查，SQL走IDX_SER_CKINVOICE_NUM这个索引是没有问题的，执行计划没有问题。
检查活动会话的等待事件：
EVENT COUNT(1)
——— ——————
cursor: mutex X 690
cursor: mutex S 89
library cache: mutex X 47
PGA memory operation 4
latch: cache buffers chains 3

通过上面可以看出，大部分的会话的等待事件cursor: mutex X，产生cursor: mutex X等待事件的原因有很多。

检查AWR报告：

检查version数高的sql：

通过检查awr报告的Mutex Sleep Summary部分，可以发现是在增加子游标的时候，导致cursor: mutex X等待事件，增加子游标慢可能是由于sql版本数太高导致的。

检查版本数高的原因：
select REASON
from v$sql_shared_cursor
where sql_id=‘5ndt9xc3y2rxr’;
…………………省略…………
通过分析上面的查询结果，检查发现版本数高，执行计划不能共享的原因Bind_equiv_
failure，也就是说，这个绑定值的选择性与用于优化现有子游标的选择性不匹配。

检查mos文档2539161.1发现，是由于触发了oracle bug 28794230，导致sql语句无法共享。

总结：通过上面分析可以看出，此次数据库cursor: mutex X问题是由于sql的版本数太高触发oracle 的bug导致的。

解决办法和建议

调整参数，需要重启数据库：
alter system set “_optimizer_use_feedback”=false scope=spfile;
alter system set “_optimizer_adaptive_cursor_sharing”=false scope=spfile;
alter system set “_optimizer_extended_cursor_sharing_rel”=none scope=spfile;
其他建议：

1. 建议对服务器内存进行扩容。
2. 也可以考虑打28794230补丁，解决上面的问题，不推荐这种方式。

参考文档

12.2 Cursor Mutex: x Due to Sql not Shared Because of Bind_equiv_failure (Doc ID 2539161.1)