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.