Oracle中qmnc是什么,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/，如需转载，请注明出处，否则将追究法律责任。