记录之前的一次非常严重的宕机故障， 当时记得出差南京的路上， 接到客户紧急电话，说是核心系统全部宕机， 数据库无法连接，数据库服务器ssh远程登录很慢，负载很高 ，最高的时候达到了80多。 情况很紧急，只能联系现场的工程师，提供SQL给他们，截图查看了等待事件， 发现有大量 cursor: mutex x等待，解决问题优先，虽然处于高峰期， 还是果断让他们执行了，清空shared pool, 情况有了一定好转， 以下是当时的一个事故分析报告：

以下是数据库基本信息，以及负载情况，负载不算特别高：

以下是数据库Top 10等待事件， 排名第一的是：cursor: mutex x

数据库的基础性能profile, 执行解析比很低

接下来看看数据库的Time Model统计， 时间都消耗在了connection和parse。

主要的SQL执行统计，发现SQL整体都不慢

一个重点发现是SQL的version非常高

问题分析及解决方案

应用系统表现比较慢，sql查询v$session, 发现大量cursor: mutex x， SQL_ID= f0h5rpzmhju11 具体的sql 如下：

select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV', 'DB_UNIQUE_NAME'), SYS_CONTEXT('USERENV', 'INSTANCE_NAME'), SYS_CONTEXT('USERENV', 'INSTANCE'), STARTUP_TIME, SYS_CONTEXT('USERENV', 'DB_DOMAIN'), SYS_CONTEXT('USERENV', 'SERVICE_NAME') from v$instance

SQL不是业务上的SQL, 是系统内部查询环境和上下文信息的SQL, 想到有大量的connection managed和mutex的等待，问题很可能和这相关， google上查找了下这个SQL_ID, 发现很多link指向是oracle的bug导致，有一些临时的workaround：

• 先查出sql address, hash_value

select address,hash_value,executions,parse_calls from v$sql where sql_TEXT like '%SYS_CONTEXT%';

• 调用存储过程purge掉此SQL在share pool latch信息

call sys.dbms_shared_pool.purge('address,hash_value','c');

• 也可以直接flush 整个share pool，但会对数据库整体性能有影响，不建议高峰期执行。

alter system flush shared_pool;

• 直接修改隐藏参数，建议在有DBA支持的情况进行，毕竟隐藏参数oracle官方不推荐。

alter system set "_cursor_obsolete_threshold"=1024

关于 cursor: mutex x

关于等待事件cursor: mutex x，原因有很多种，具体的分析，下次统一写一个文档。

参考信息

NOTE:438755.1 - High SQL Version Counts - Script to determine reason(s)

High Version Count with CURSOR_SHARING = SIMILAR or FORCE (Doc ID 261020.1)

Troubleshooting: High Version Count Issues (Doc ID 296377.1)

Patch 25054064: TST&PERF:EBS: VERY HIGH VERSION COUNT AND CURSOR MUTEX WAITS AFTER PLUG INTO CDB