Stream Performance

Question

Hi,
We are working on Oracle 9i bi-directional Stream replication between two remote databases. We have following system configuration :
MS Windows 2K OS
Pentium IV Processor with 1.7 GHz
1 GB RAM
We have more than 100 tables for replication purpose. In stream set up, we have two different queues, one for capture and another for apply. It was working fine earlier. As sson as we restarted both the db srvrs, Oracle.exe thread staretd taking almot 95-99% of CPU, and we tried to recover from this, we could not. and after some time, both the systems stopped functioning.
What might be the possible reason for this ?
Thanx, & regards,
Kamlesh

Answer 1

Here are a couple of performance tips:
1) Make sure that you have installed either the 9.2.0.2 or 9.2.0.3 patchset. 9.2.0.2 is a required patch for databases participating in Oracle Streams. The 9.2.0.3 patchset includes the 9.2.0.2 patches and is a recommended patchset for Oracle Streams databases.
2) Increase the shared_pool size .
Each capture process requires 10Mb of shared pool. If the parallelism parameter of capture is greater than 2, then the memory required is 10Mb * parallelism
In addition to the memory required for the capture process, there is an in-memory buffer queue which holds all of the logical change records(LCRs) for streams requires memory from the shared pool. The buffer queue memory requirement for a database is limited to 10% of the memory allocated with the shared_pool_size init.ora parameter. Therefore, with a 200Mb shared_pool_size, up to 20Mb is available for the use of the in-memory buffer queue(s).
When the buffer queue memory threshold is exceeded, LCRs will spill-over to disk and continue to spill to disk until all of the transactions have been consumed by all down-stream sites. When this spill-over occurs, streams performance is impacted.
3) Relocate the Streams data dictionary tables away from the SYSTEM tablespace.
4) For bi-directional replication, configure two (2) queues to minimize spill-over from buffer queue to disk.
5) Make sure that rules are simple To make a quick determination if an event (LCR) is "interesting", fast rule evaluation preprocessing can be used on rules with object_owner, object_name, source_database_name specified in simple equality statements. Avoid 'LIKE' and 'NOT' operators in rules as fast rule evaluation preprocessing cannot be utilized.
6) Make sure that the init.ora parameter aq_tm_processes is set to a non-null value. This is the parameter that enables the purging of the queue. If the queue is never purged, the in-memory buffer will, sooner or later, spill over to disk.