Oracle等待事件curror：mutex故障分析

1、收到业务通知反馈数据库频繁锁表的问题

2、分析过程

查看故障时段的awr

发现 sql的版本数太高了

3、等待事件

curror：mutex :

cursor正在被解析并尝试以独占(exclusive)模式获取cursormutex时产生的等待即为cursor：mutexx

跟 _cursor_obsolete_threshold隐含参数有关

_cursor_obsolete_threshold：在11.2.0.3之后， _CURSOR_OBSOLETE_THRESHOLD，其作用是当SQL版本超过这个参数设定后，直接舍弃这个游标，重新解析，重头开始。在这一版本之前，通过补丁和参数（"_cursor_features_enabled" 和 event 106001）可以达成类似的效果

4、查看数据库该参数的值

发现该参数的值是8192

根据MOS文档（2431353.1）建议调整改参数的值为102

5、继续分析数据库sql 子游标数量多，出现解析缓慢的现象

查看数据库字符集

CDB：

PDB：

发现数据库的CDB和PDB的字符集不一致，可能触发bug25054064了，我们这库是CDB模式，并且PDB的字符集不一致。通过MOS查找到一篇类似的文章（Doc ID 25054064.8）

另外由于字符集不匹配导致的数据库sql子游标数量多，出现解析缓慢的现象在（DocID 2542447.1）也详细介绍了处理方法，用于缓解子Cursor过多查找缓慢导致的等待

6、处理建议

1、通过具体SQL_ID将其从sharedpool清除掉

2、将_cursor_obsolete_threshold设置为 1024 或任何值（取决于您的应用程序要求），以便在父游标具有超过 1024个子游标或任何设置的值时，父游标将被淘汰，需要重启cdb生效.