操作系统类型：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。
如果，您知道更好的处理方法，请您留言！