Now that we know about the Capture process, it is time to move to the Propagate process. The Propagate process does the actual Propagation between the source and target queues.
Propagation has two configuration options, queue-to-queue or queue-to-dblink. In the queue-to-queue configuration, each Propagation has its own propagation job. This allows multiple Propagations to be configured and scheduled to propagate at different times. It should be noted that queue-to-queue propagation is recommended for Streams in an RAC environment. The default configuration of queue-to-dblink has one shared propagation job. For queue-to-dblink configurations, having one shared propagation job may cause issues because making any propagation schedule change affects all the propagations that rely on the source queue and database link. This issue can be overcome by configuring different queues when using queue-to-dblink. For example, one queue would be set up QUEUE1 and be on its own SCHEDULE. Then a separate queue, QUEUE2 can be set up and have its own SCHEDULE. Propagation scheduler will be covered in a moment.
Propagation can be configured to propagate to different targets. With the use of RULES one can set up multiple Propagate processes, referencing one buffer queue on the Source. Each Propagation process will process from the same source queue. The source queue will only delete the LCR once it is consumed by each Propagation process registered as a consumer of the queue.
At this time, we need to mention Secure Queue. A secure queue can be used only by the owner of that secure queue. Think of it this way, the owner of the queue runs and controls it. No other users or processes may use a secure queue unless the owner allow it by granting explicit privileges to the user. For the purpose of this book, all queues will be secure queues. This is compared to an unsecure queue which any session or process is allowed to use.
So, how does Propagate know when to do its job? In Oracle 11g, Scheduler controls when the Propagation takes place (in previous versions, it was accomplished via regular database jobs). Later, when we work through our example Streams configurations, we will accept the default propagation schedule.
"What" gets propagated "Where" is controlled via Propagation rules is just like "What" is captured by the Capture process that is controlled via Capture rules. The creation of these rules is very similar to Capture process rules, so we won't go into the same level of detail again. Propagation process and rules can be created using either the DBMS_STREAMS_ADM.ADD_*_PROPAGATION_RULE for the replication level desired, or via the DBMS_PROPAGATION_ADM.CREATE_PROPAGATION procedure.
The main thing to understand is that Propagation needs to know what queue from which it must dequeue captured LCRs, what database link to use to send the changes and the destination database name, as well as the remote queue at the destination database in which to enqueue the LCR. As with Capture rules, you can control what the Propagation process sends based on the same type of parameters and rule conditions used in the Capture process.
It should be noted that even though you create a Propagation process using either the DBMS_STREAMS_ADM or DBMS_PROPAGATION_ADM procedures, you use the DBMS_AQADM Propagation Subprograms to schedule/unschedule, alter, enable, and disable propagation. You use the DBMS_PROPAGATION_ADM subprograms to create drop, start, and stop propagation jobs. This is because the Propagation process is separate from the propagation job. The Propagation process can remain running while the propagation job is disabled. This separation allows Streams to support queue-to-queue Propagation as well as queue-to-dblink propagation. Understanding the separation of the two, aids in understanding what procedure to use to control which piece of Propagation.
You can see this separation of duties by looking at the background processes for Propagation. The Propagation processes (similar to the Capture processes) are designated by Pnnn, where as the propagation jobs are separate job processes designated by Jnnn.
Note
For more detailed information on creating and managing Propagation processes and schedules, please refer to the Oracle Streams Concepts and Administration Guide and the Oracle PL/SQL Reference and Types manual.
If you have a job title that ends in "Administrator", such as "DBA", you know one thing for sure and that is that the bottom line performance is dependent on the quality of hardware and network. To a certain point, Administrators hit the hardware or network performance wall and no amount of configuration tweaking will change the performance levels. As a DBA, we (hopefully) have some influence on the hardware selection for our databases. DBAs often have little (or no) input as to the network configuration or network hardware selected.
Why is this important? Streams depends on both hardware and network. If you have slow hardware and/or network, you can expect Streams to have low performance levels. The performance of Streams relates directly to your hardware and/or network limitations.
It is with this in mind that we address how to measure the network performance and its potential impact on Propagation before implementing Streams. In many cases Streams database links are configured to use the aliases in TNSNAMES.ORA. The TNSNAMES.ORA DESCRIPTION format can use different network protocols, though most often we see (PROTOCOL=tcp). Measuring, and knowing the network speed and protocol used between the SOURCE and TARGET nodes is important when diagnosing overall Streams' performance. We cover this in more detail in Chapter 3.
We are not saying "blame the network" when a performance problem occurs with Streams. What we wish to convey is that there are parts of the Streams environment that are in your direct control. There are also parts that are beyond your control that affect Streams' performance. Knowing how the network performs is crucial to your ability to diagnose all Streams' performance. Having a good working relationship with your Network Admin will also help when such problems arise. By working with the Network Admin closely, you may also be able to establish minimum service level agreements as well as set realistic client or user expectations where performance is concerned.
How does a propagation job know that its payload has been successfully received and stored at the destination site? This is accomplished via Oracle's guaranteed fail-safe Propagation protocol that requires return notification of a successful commit of the LCR payload data at the destination before it allows the LCR to be removed from the Capture queue and the Capture REQUIRED_CHECKPOINT_SCN to be moved beyond that LCRs' SCN. If, after a number of tries (16 to be exact) destination enqueue fails, an error is logged in the DBA_QUEUE_SCHEDULES and DBA_PROPAGATION view, the propagation job will be disabled and will require manual restart.
Not all COMLINKs are created equal (unfortunately). It is quite possible to have a distributed environment where some network connections from a source database to the different destination databases may not move Streamed data at the same rate, or be equally stable. This inequality of transport to multiple destinations can cause the source queue to grow undesirably large as a result of enqueued LCRs that cannot be deleted until the destination site has confirmed receipt and successful enqueue of the LCR. This could result in Spilled transactions (the LCRs are written to disk from the buffered queue), and memory resource consumption. This also creates a negative performance impact as propagation jobs must scan all the entries in the queues to determine which they have and have not sent. In previous releases, the way to circumvent this was to create a separate capture queue that was used for slower moving or unstable destination connections. This allowed jobs using faster and more stable network connections to be assigned to less encumbered queues. 11g brings the ability to have the Propagation process create these types of queue segmentations on the fly, as needed, via Streams Split and Merge. A Propagation process can be configured to recognize when a destination site is exceeding expected transport times. If this happens, the Propagation process will (in a nutshell) clone the Capture process and queue, spawn a separate Propagation job from the cloned queue to the "slow" destination and remove the original Propagation job for the destination from the original queue. In essence, it "splits" the slow stream off to a separate queue allowing the original queue to service the faster destination Propagation processes without performance impact. If/when transport times for the "Split" destination Propagation return to normal, the cloned Capture process can be started to allow the rogue destination site to catch up. Once it does, the queues and processes are merged back to their original configuration automatically. We cover more on Stream Split and Merge in more detail in Chapter 6.
The following lists Propagation/Scheduler views that contain helpful information concerning your Propagation processes and job:
DBA_PROPAGATIONV$BUFFERED_SUBSCRIBERSV$BUFFERED_PUBLISHERSV$PROPAGATION_RECEIVERV$PROPAGATION_SENDERDBA_SCHEDULER_JOBS(filter on JOB_CLASS = 'AQ$_PROPAGATION_JOB_CLASS')