Parameter AQ_TM_PROCESSES Oracle Streams Advanced Queuing User's Guide and Reference (http://download.oracle.com/docs/cd/B19306_01/server.102/b14257/aq_intro.htm) "If you want to disable the Queue Monitor Coordinator, then you must set AQ_TM_PROCESSES = 0 in your pfile or spfile. Oracle strongly recommends that you do NOT set AQ_TM_PROCESSES = 0. If you are using Oracle Streams, then setting this parameter to zero (which Oracle Database respects no matter what) can cause serious problems." There's something special about this parameter. First, if you don't explicitly set it in pfile or spfile, its value is shown as 0 in v$parameter or show parameter. Of course you can tell if it's explicitly set by checking v$parameter.ismodified. With this implicit 0 value, you still see QMNC background process and q00x (x is a number) user processes, possibly waiting on 'Streams AQ:%' events. It's unlikely you're using Oracle Streams technology. So you can completely shutdown these processes by explicitly setting the parameter to 0: alter system set aq_tm_processes = 0. However, there're some side effects as a result of not running these AQ related processes. Data pump no longer works, throwing error like "ORA-39079: unable to enqueue message" (see e.g. Doc 816839.1 or Bug 5490029). [Update 2015-06] This no longer applies in 11g; data pump works even with aq_tm_processes set to 0. Secondly, the table sys.sys$service_metrics_tab in sysaux tablespace may grow and never get shrunk. This table is related to AWR (automatic workload repository) in spite of the words "Space usage by non-AWR components" for this table in the output of $ORACLE_HOME/rdbms/admin/awrinfo.sql, and is a queue table (appears in dba_queue_tables) even though you're not using Advanced Queuing. (The table grows even faster if you have extended retention time by dbms_workload_repository.modify_snapshot_settings.) To shrink the table, you have to set aq_tm_processes to a non-zero number or unset it to let Oracle decide on its value. Once you do that, the q000 process is created and starts to consume quite a bit of CPU to move rows in the table from state 0 to 2, and later delete them.[note] Since the table segment remains in its size, you can alter table sys$service_metrics_tab shrink space. (Note: That command places a TM lock on the table in mode 6, possibly blocking processes MMON and q001; to limit the impact, you can shrink space compact first, which locks in mode 3, followed by shrink space.) So what's the best strategy about the setting? I think you can have a job to explicitly set the parameter to 0 during busy time (e.g. daytime) and explicitly set it to 1 during quiet time (night or weekend, and that may be the time most expdp jobs runs). Or if you have a RAC with one node dedicated to administrative tasks, set the parameter to 1 on that node only (and schedule expdp jobs there only) and set it to 0 on all others, regardless time. But if q000 process doesn't consume much CPU according to --Top 5 cumulative CPU sessions (assume stat# 12 is 'CPU used by this session' in 10g) select sid, value from (select * from v$sesstat where statistic# = 12 order by value desc) where rownum <= 5; --How much does q00% use? select a.sid, value from v$session a, v$sesstat b where program like '%q00%' and a.sid = b.sid and b.statistic# = 12; then there's not much benefit to make any change. ____________________ [note] According to SR 7157198.994, the correct way to say is "The queue SYS.SYS$SERVICE_METRICS_TAB is used by MMON who is responsible for inserting rows, however the underlying AQ functionality is needed to maintain the queue." Also, QMON changes the state from READY to PROCESSED, and MMON dequeues the messages and removes the actual rows from the queue table.