在oracle11.2.0.1版本中如何快速解决Cursor Mutex S事件

 

    可是人就是这样，总会活在某个时限内，那里的世界也许是几年之后连自己都无法理解的，但这又是我们无法突破的。为你，千千万万遍，遍体鳞伤还是会义无反顾，也许这就是人生，人生不是只做值得的事情!

                                                                  <<追风筝的人>>

 

                           

    

    “Cursor Mutx S”，看字面意思，就知道和sql执行争用有关系。当一个回话以共享模式去请求一个sql游标mutex时，发现其他会话以排他模式占用着该mutex，导致等待。

 

    该问题在oracle官网中给出了解释，主要由bug导致，在11.2.0.1后续版本中fixed。

 

    在oracle 11.2.0.1版本中，sql语句执行，因多版本执行计划问题，sql执行使用了错误的（最差的，最耗费资源的）执行计划，导致后续相同语句执行引起争用，出现“Cursor Mutex S"事件，导致cpu被大量占用，数据库非常缓慢！

 

1，解决办法：

    A，清空共享池（注意：不推荐使用该方法，特别是生产系统）

alter system flush shared_pool;

 

    B，对语句中的对象进行ddl（这显然不现实）

drop table test;

 

    C，重新收集统计信息（也不太可行，特别是生产系统约束很多，也不见得有效）

 analyze table test compute statistics;

 

    D，在oracle版本10.2.0.4后，oracle提供了一种通过指定sql语句参数，进行共享池sql清理的方法（推荐方法）：

exec dbms_shared_pool.purge('0000000E1EB2D8F0,791711688','C');

 

    exec dbms_shared_pool.purge('0000000E1EB2D8F0,791711688','C');

        第一个参数：sql语句对应的地址

        第二个参数：sql语句对应的hash值

        第三个参数：代表clear的意思

 

    参数值可以通过查询获得：

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

 

2，测试

    以下通过本地库一条sql语句来测试dbms_shared_pool.purge的作用

 

    创建表：

SQL> create table test(id int);表已创建。

 

    查询表，多执行几次

SQL> select * from test;未选定行

 

    获取sql address等信息

SQL> select address,hash_value,executions,parse_calls from v$sql where sql_TEXT like 'select * from test%';ADDRESS          HASH_VALUE EXECUTIONS PARSE_CALLS---------------- ---------- ---------- -----------0000040229F039E0 1689401402          1           1

 

    清理

SQL>exec dbms_shared_pool.purge('0000040229F039E0,1689401402','C');PL/SQL 过程已成功完成。

 

    查看sql信息

SQL>select address,hash_value from v$sql where sql_text like 'select * from test%';未选定行

 

    可以看到，视图中已经没有看到对应sql的信息了，可见共享池中sql的执行计划已经被清理。

 

    在生产系统中，如果我们出现上述事件，也可以通过该方法快速完成对应sql的清理清理，确保系统的稳定运行！

 

                                              欢迎大家关注以下公众号进行数据库方面知识探讨：