Aq$_tab_p, aq$_tab_d filling and not being cleaned up

Question

Hi all.
I have a simple 1 way streams replication setup (two node) based on examples. Replication seems to be working.
However, the AQ$_TAB_P and AQ$_TAB_D (on the capture side only) tables continue to fill (as well as number of messages in the queue and spilled lcrs in v$buffered_queues). Nothing should be spilling since the only things I'm sending are 1 row updates to a heartbeat table and the streams pools are a few hundred meg.
I have tried aq_tm_process unset, as well as set to 2 and the tables continue to grow.
The MSG_STATE in aq$tab are either DEFERRED or DEFERRED SPILLED. As mentioned all of the heartbeat updates ( as well as small test transactions ) replicate just fine, so the transactions are being captured,propagated and applied.
I am running 10.2.0.2 on solaris 10 with no streams related one off patches to speak of, for reference. My propagation did not specify queue_to_queue.
I'm wondering if there is a step I may have missed, or what else I may be able to look at to ensure that these tables are cleaned up?
Thanks.
Edited by: user599560 on Oct 28, 2008 12:39 PM

Answer 1

Hello
I forgot to mention that you should check v$propagation_receiver on the destination and v$propagation_sender on the source. v$propagation_receiver on the source will not have records unless you are using bi-directional streams.
The aq_tm_processes parameter should be set on all the databases that uses Streams. This parameter is responsible for spawning the number of queue monitor slaves which is actually performing the spilling and removing the spilled messages which are no longer needed.
It is suggested to remove this parameter from spfile, however your SHOW PARAMETER will still show this as 0. Hence you should be checking v$spparameter to confirm whether this was actually removed from it. If you remove it from the spfile, then it should spawn the required number of slaves automatically as per the autotune feature in 10g. However I would always suggest to set this parameter to 1 so that one slave process will be always spawned even if we dont use Streams and SHOW PARAMETER always show this as 1.
If you find the slaves are not spawned, then you should be checking your alert.log to see whether any errors are reported. You need to check the Queue Monitor Coordinator process qmnc is spawned. If qmnc itself is not spawned (by default it should be spawned always), then no q00 slaves will be spawned. If you remove the parameter from spfile and you see that no q00 slaves are spawned eventhough you are using Streams (either capture, prop or apply) then you should log an SR with Oracle Support to investigate this. You can check the qmnc and q00 slaves at the OS level using the following command:
ps -ef | grep $ORACLE_SID | grep [q][m0][n0]
Please mark this thread as answered if all your questions are answered well else let me know.
Thanks,
Rijesh