You've seen these movies and heard the famous songs where, when certain planets align in certain ways at certain times, special powerful things automatically happen. As of 11g, Streams has such a cosmic event potential. And when this cosmic event occurs, its called Combined Capture and Apply. Seriously, it really is like a cosmic event in the galaxy of optimization. When Oracle Streams is configured a particular way between two sites, the Capture process acts as the propagator, using its associated Propagation process rule set, and transmits the eligible LCR's directly to the Apply process at the destination via database link. This functionality automatically detects if the optimal configuration is in place and "flips the switch" to enable Combined Capture and Apply. The only way to control whether or not Combined Capture and Apply is enabled, is to change the configuration of your Streams so that one of the configuration "rules" is violated.
The configurations that cultivate this cosmic event are a little different depending on where the Apply process resides.
If the Apply process resides in a different database than the Capture process, the configuration is required:
The Capture and Apply databases must be on release 11g Release 1 or higher
The Capture process is the only publisher for the capture queue
Propagation is configured directly between the capture and apply queues (no intermediate queues allowed)
The Propagation is the only consumer for the Capture queue
The Propagation is the only publisher for the Apply queue
If a buffered Apply queue is used, the Apply process can be the only consumer for the queue
If a persistent Apply queue is used, multiple Apply processes can be consumers for the queue
One behavior to point out here is that if the Apply process is unavailable at the destination database, the Capture process will hang in the INITIALIZING state at startup until the Apply process becomes available. Once the Apply process is enabled, the Capture process immediately transitions to CAPTURING CHANGES.
If the Apply process resides in the same database as the Capture process, the configuration is required:
The database must be on release 11g Release 1 or higher
The Capture and Apply process use the same queue
The Capture process is the only publisher for the queue
Propagation is configured directly between the capture and apply queues (no intermediate queues allowed)
If a buffered queue is used, the Apply process can be the only consumer for the queue
If a persistent queue is used, multiple Apply processes can be consumers for the queue
As the user has no control over the enablement of Combined Capture and Apply (CCA) beyond setting up the Streams configuration, it may not be immediately obvious when Combined Capture and Apply is enabled. You can determine if it is enabled by checking the V$STREAMS_CAPTURE and V$STREAMS_APPLY_READER views.
In V$STREAMS_CAPTURE, the APPLY_NAME will have the name of the Apply process and the OPTIMIZATION will be greater than 0 (zero, zed) if CCA is enabled.
select capture_name, apply_name, optimization from V$STREAMS_CAPTURE; CAPTURE_NAME APPLY_NAME OPTIMIZATION ------------------ ----------------------- ------------ HR_CAPTURE HR_APPLY 2
The PROXY_SID is not NULL in V$STREAMS_APPLY_READER.
select apply_name, proxy_sid from V$STREAMS_APPLY_READER; APPLY_NAME PROXY_SID ------------------------------ ---------- HR_APPLY 132
You will also see a similar entry in the alert log:
Propagation Sender (CCA) HR_PROPAGATION for Streams Capture HR_CAPTURE and Apply HR_APPLY [on destination STRM2] with pid=28, OS id=6096 started.
When Streams is in Combined Capture and Apply mode, you will not see information concerning the Propagation in the DBA_QUEUE_SCHEDULES view. In this case, you will need to query the V$PROPAGATION_SENDER and V$PROPAGATION_RECEIVER views.