導致這個問題的主要原因與初始化引數AQ_TM_PROCESSES有關。

• 分析方法

       檢視引數AQ_TM_PROCESSES的值，按照10g官方文件提示，AQ_TM_PROCESSES=0，qmn監控程序是沒有啟動的，只有設定為1到10之間才能啟動，可以根據實際情況設定。 

          設定：alter system set AQ_TM_PROCESSES=1; 

10g的預設值為0，設定區間為1-10；

11g的預設值為1，設定區間為1-40；

       由於Oracle的高階佇列、流、資料泵等多種內建功能都會依賴於QMN程序，當AQ_TM_PROCESSES不為0時，Oracle無法自動根據負載確定QNNN程序的數量，來滿足佇列相關操作的需求。而如果該引數被禁止，Oracle只能在出現佇列需求的時候才被動的去啟動一個SLAVE程序，從而導致了較高的平均等待時間。

      Streams AQ: qmn coordinator waiting for slave to start等待事件等待的次數非常少，在一個小時的AWR報告中就出現了2次，但是每次的等待時間卻非常長，平均達4秒以上。在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自動分配。

      取消aq_tm_processes引數的設定：      alter system reset aq_tm_processes scope=spfile sid=\'*\';