ORACLE11G QMNC引起的library cache: mutex X

   操作系统类型：Linux ### 2.6.39-400.17.1.el6uek.x86_64 #1 SMP Fri Feb 22 18:16:18 PST 2013 x86_64 x86_64 x86_64 GNU/Linux   
   数据库版本：SQL*Plus: Release 11.2.0.4.0 Production
   数据库类型：OLAP
   问题现象描述：最近通过linux的top发现有2个进程始终占用CPU90%左右，如下图所示：
      
   然后查看相关进程发现时QMNC相关的Q000、Q0001
[ oracle@ora29 ~]$ ps -ef|grep 3294
oracle    3294     1 95 May30 ?        18:39:16 ora_q000_ora29a
oracle   22955 20556  0 11:23 pts/3    00:00:00 grep 3294
[oracle@ora29 ~]$ ps -ef|grep 3296
oracle    3296     1 85 May30 ?        16:34:42 ora_q001_ora29a
oracle   23037 20556  0 11:23 pts/3    00:00:00 grep 3296
   然后，去数据库中查相关进程的等待情况，如下：
select sid,spid, osuser, s.program from v$session s,v$process p where 
s.paddr=p.addr and spid=&spid;
new   2: s.paddr=p.addr and spid=3294

       SID SPID                     OSUSER                           PROGRAM
---------- ------------------------ ------------------------------ ------------------------------------------------
       336 3294                     oracle                           oracle@ora29 (Q000)
select sid,wait_class_id,user#,username,lockwait,status,osuser,sql_id,PREV_SQL_ID from v$session where 
wait_class_id=3875070507 and sid=&sid;
new   2: wait_class_id=3875070507 and sid=336

       SID WAIT_CLASS_ID      USER# USERNAME            LOCKWAIT       STATUS   OSUSER              SQL_ID            PREV_SQL_ID
----------   -------------              ---------- --------------- ----------------                 --------      ---------------     -------------        -------------
    336    3875070507                  0                                                  ACTIVE     oracle                                   cb21bacyh3c7d

  查询结果，发现336会话没有当前执行的SQL语句。
 网上查询说library cache: mutex X等待可能发生在buncket上，也可能发生在handle上，通过查询，发现等待是发生在handle上。
select kglnaown, kglnaobj
      from x$kglob
     where kglnahsh = &p1;
new   3:      where kglnahsh = 3793251071

KGLNAOWN                                                               KGLNAOBJ
---------------------------------------------------------------- ----------------------------------------
SYS                                                             SCHEDULER$_EVENT_QUEUE
  然后，通过dba_objects查询了该对象的信息，发现5月25日，它发生了DDL：
OWNER        OBJECT_NAME        SUBOBJECT_NAME        OBJECT_ID        DATA_OBJECT_ID        OBJECT_TYPE        CREATED        LAST_DDL_TIME        TIMESTAMP        STATUS        TEMPORARY        GENERATED        SECONDARY        NAMESPACE        EDITION_NAME
   SYS        SCHEDULER$_EVENT_QUEUE                12223                QUEUE        2009/8/15 0:23:53       2016/5/25 16:10:40        2016-05-25:16:10:40        VALID        N        N        N        10        
  查询其他同版本的数据库实例，SCHEDULER$_EVENT_QUEUE对象没有发现有DDL发生。
  问题到这里，没有找到最好的处理方法，临时解决方法是：关闭QMNC，方法就是把 aq_tm_processes置为零，该参数是动态可以修改的。
SQL> show parameter aq_tm_processes
NAME                                      TYPE         VALUE
------------------------------------         ----------- ------------------------------
aq_tm_processes                    integer         0
  QMNC关闭后，服务器CPU恢复正常：

  QMNC与q00n是负责维护AQ表的，QMNC进程会监视高级队列，并警告从队列中删除等待消息的“出队进程”（dequeuer）：已经有一个消息变为可用。QMNC和Qnnn还要负责队列传播（propagation），也就是说，能够将在一个数据库中入队（增加）的消息移到另一个数据库的队列中，从而实现出队。QMNC是个可选的功能，处于演示保障CPU，临时关闭QMNC。
  如果，您知道更好的处理方法，请您留言！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29357786/viewspace-2109739/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29357786/viewspace-2109739/