导致这个问题的主要原因是初始化参数AQ_TM_PROCESSES设置为0，而Oracle推荐改参数应该至少设置为1。由于Oracle的高级队列、流、数据泵等多种内置功能都会依赖于QMN进程，当AQ_TM_PROCESSES不为0时，Oracle无法自动根据负载确定QNNN进程的数量，来满足队列相关操作的需求。而如果该参数被禁止，Oracle只能在出现队列需求的时候才被动的去启动一个SLAVE进程，从而导致了较高的平均等待时间。

Streams AQ: qmn coordinator waiting for slave to start等待事件很少见到，今天在查看一个客户的AWR报告中发现了这个等待事件，AWR报告的TOP如下：

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
DB CPU		308		62.85
db file sequential read	92,033	96	1	19.60	User I/O
db file scattered read	44,852	90	2	18.39	User I/O
Streams AQ: qmn coordinator waiting for slave to start	3	16	5269	3.23	Other
gc cr grant 2-way	60,943	11	0	2.27	Cluster

Streams AQ: qmn coordinator waiting for slave to start等待事件等待的次数非常少，在一个小时的AWR报告中就出现了3次，但是每次的等待时间却非常长，平均达5秒以上。在10g版本中，QMON（Queue Monitor Processes）自动协调slave经常的分配，aq_tm_processes无需在手动设置，slave进程会在需要的时候自动分配。
查看了用户的aq_tm_processes参数为0，数据库版本为10.2.0.5（oracle是不建议将aq_tm_processes设置为0的),那说明此时oracle在自动分配slave进程时时存在问题的，效率过低，所以如果出现Streams AQ: qmn coordinator waiting for slave to start等待事件，还是建议将aq_tm_processes参数设置为非零值，让oracle预先分配几个slave进程，该参数的取值范围是0~10，或者取消aq_tm_processes参数的设置，让oracle自动分配。
可以通过下面的代码查看QMON自动调整是否启用，同时aq_tm_processes参数是否被设置为0：

connect / as sysdba
set serveroutput on
declare
mycheck number;
begin
select 1 into mycheck from v$parameter where name = 'aq_tm_processes' and value = '0' and (ismodified != 'FALSE' OR isdefault = 'FALSE');
if mycheck = 1 then
dbms_output.put_line('The parameter ''aq_tm_processes'' is explicitly set to 0!');
end if;
exception when no_data_found then
dbms_output.put_line('The parameter ''aq_tm_processes'' is not explicitly set to 0.');
end;
/

取消aq_tm_processes参数的设置：

connect / as sysdba
alter system reset aq_tm_processes scope=spfile sid=\'*\';

补充：从11.2.0.3以后的版本中，aq_tm_processes默认值又调整为1.

-----------------------------------------