背景：

v$session中同一个sql语句bhaku1zp2w5v7大量等待cursor: mutex X ，且等待事件较长。

分析：

什么是cursor: mutex X？

任何操作或访问游标的操作都可能需要等待访问共享池中支持游标的结构。在极端争用的情况下，这些等待可能会成为一个重大瓶颈，并可能限制正常活动。从 10.2 开始，一些共享游标操作开始由 Oracle 的 Mutex 功能实现，并且在 11g 中，Librarycache 和 rowcache 组件也使用 Mutex 实现。

等待游标是解析时间等待，涉及将游标加载到共享池中或搜索这些游标。大多数问题的发生是由于：

* 共享池中游标的版本数过多

* 过多的硬/软解析

* 过多的失效/重新加载

* 加载了巨大的对象

* 大小不合适的共享池

* OS/Resource Manager 正在调度的 Off CPU 资源的持有者

* 操作系统内存管理（例如，Linux x86-64 平台上的超大型 SGA，没有实施 Hugepages）

* 代码缺陷

对这些事件的争用通常是另一个问题的征兆 - 表明其他地方存在问题，而不是结构或机制本身的问题。要解决此症状，需要确定并解决根本原因。

v$sqlarea查看游标数，8025个子游标

SQL>  select address,hash_value,version_count from v$sqlarea where sql_id='bhaku1zp2w5v7';

ADDRESS          HASH_VALUE VERSION_COUNT
---------------- ---------- -------------
0000000313A24238 3928889191          8025

v$sql_shared_cursor检查游标无法共享原因

绝大部分是由于BIND_EQUIV_FAILURE，绑定值的选择性与用于优化现有子游标的选择性不匹配。

SQL> select * from v$sql_shared_cursor where sql_id='bhaku1zp2w5v7';

Y对应BIND_EQUIV_FAILURE，即游标无法共享原因，绑定值的选择性与用于优化现有子游标的选择性不匹配
BIND_EQUIV_FAILURE VARCHAR2(1) (Y|N) The bind value's selectivity does not match that used to optimize the existing child cursor

SQL> select count(*) from v$sql_shared_cursor where sql_id='bhaku1zp2w5v7'  and BIND_EQUIV_FAILURE='Y';

  COUNT(*)
----------
      7136

匹配 bug 28794230

Bug 28794230  12.2 Cursor Mutex X Due To Sql Not Shared Because Of BIND_EQUIV_FAILURE

版本匹配，12.2.0.1，当前版本12.2.0.1.201020

解决方案

Description
Cursor leak with ACS(Adaptive Cursor Sharing) and CFB(Cardinality FeedBack) 
on short-running query and fix for Bug:23596611.
  
Rediscovery Notes
If a subsecond query with binds exhibits increasing child cursor count on
repeated executions on a release where the fix for Bug:23596611 exists and
disabling adaptive cursor sharing or statistics feedback prevents the cursor leak ,t
hen you may have encountered this bug.
 
You can see  BIND_EQUIV_FAILURE=Y in V$SQL_SHARED_CURSOR.
 
Workaround
Several alternatives:
_optimizer_use_feedback=false
_optimizer_adaptive_cursor_sharing=false
_optimizer_extended_cursor_sharing_rel=none
_fix_control='23596611:OFF'  may also help in some cases

建议：

1.安装28794230 oneoff patch。需要申请窗口实施。

2.设置隐含参数，需要窗口重启实例生效。

_optimizer_use_feedback=false

_optimizer_adaptive_cursor_sharing=false

_optimizer_extended_cursor_sharing_rel=none

3.绑定sql执行计划（最终选用这种方式，变动最小原则）