This chapter describes the best practices for propagating messages in a Streams replication environment. This chapter includes these topics:
This following sections describe best practices for configuring propagations:
A propagation can be queue-to-queue or queue-to-database link (queue-to-dblink). Use queue-to-queue propagations whenever possible. A queue-to-queue propagation always has its own exclusive propagation job to propagate messages from the source queue to the destination queue. Because each propagation job has its own propagation schedule, the propagation schedule of each queue-to-queue propagation can be managed separately. Even when multiple queue-to-queue propagations use the same database link, you can enable, disable, or set the propagation schedule for each queue-to-queue propagation separately.
Propagations configured prior to Oracle Database 10g Release 2 are queue-to-dblink propagations. Also, any propagation that includes a queue in a database prior to Oracle Database 10g Release 2 must be a queue-to-dblink propagation. When queue-to-dblink propagations are used, propagation will not succeed if the database link no longer connects to the owning instance of the destination queue.
If you have queue-to-dblink propagations created in a prior release of Oracle Database, you can re-create these propagation during a maintenance window to use queue-to-queue propagation. To re-create a propagation, complete the following steps:
Stop the propagation.
Make sure the source queue is empty.
Make sure that the destination queue is empty and has no unapplied, spilled messages before you drop the propagation.
Re-create the propagation with the queue_to_queue
parameter set to TRUE
in the creation procedure.
See Also:
"Follow the Best Practices for Configuring and Managing Propagations" for information about propagations in a RAC environment
Oracle Streams Concepts and Administration for information about creating propagations
Propagation latency is the maximum wait, in seconds, in the propagation window for a message to be propagated after it is enqueued. Set the propagation latency to an appropriate value for each propagation in your Streams replication environment. The default propagation latency value is 60.
The following scenarios describe how a propagation will behave given different propagation latency values:
If latency is set to 60, and there are no messages enqueued during the propagation window, then the queue will not be checked for 60 seconds for messages to be propagated to the specified destination. That is, messages enqueued into the queue for the propagation destination will not be propagated for at least 60 more seconds.
If the latency is set to 600, and there are no messages enqueued during the propagation window, then the queue will not be checked for 10 minutes for messages to be propagated to the specified destination. That is, messages enqueued into the queue for the propagation destination will not be propagated for at least 10 more minutes.
If the latency is set to 0, then a job queue process will be waiting for messages to be enqueued for the destination and, as soon as a message is enqueued, it will be propagated. Setting latency to 0 is not recommended because it might affect the ability of the database to shut down in NORMAL
mode.
You can set propagation parameters using the ALTER_PROPAGATION_SCHEDULE
procedure from the DBMS_AQADM
package. For example, to set the latency of a propagation from the q1
source queue owned by strmadmin
to the destination queue q2
at the database with a global name of dbs2.net
, log in as the Streams administrator, and run the following procedure:
BEGIN DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE( queue_name => 'strmadmin.q1', destination => 'dbs2.net', latency => 1, destination_queue => 'strmadmin.q2'); END; /
Note:
If thelatency
parameter is not specified, then propagation latency is set to the default value of 60.When using Streams propagation in a Wide Area Network (WAN), increase the session data unit (SDU) to improve the propagation performance. The maximum value for SDU is 32K (32767). The SDU value for network transmission is negotiated between the sender and receiver sides of the connection, and the minimum SDU value of the two endpoints is used for any individual connection. To take advantage of an increased SDU for Streams propagation, the receiving side sqlnet.ora
file must include the DEFAULT_SDU_SIZE
parameter. The receiving side listener.ora
file must indicate the SDU change for the system identifier (SID). The sending side tnsnames.ora
file connect string must also include the SDU modification for the particular service.
In addition, the SEND_BUF_SIZE
and RECV_BUF_SIZE
parameters in the listener.ora
file increase the performance of propagation on your system. These parameters increase the size of the buffer used to send or receive the propagated messages. These parameters should only be increased after careful analysis of their overall impact on system performance.
The following section describes best practices for operating existing propagations.
Sometimes, the propagation job for a propagation might become "broken" or fail to start after it encounters an error or after a database restart. Typically, stopping and restarting the propagation solves the problem. For example, to stop and restart a propagation named prop1
, run the following procedures:
BEGIN DBMS_PROPAGATION_ADM.STOP_PROPAGATION( propagation_name => 'prop1'); END; / BEGIN DBMS_PROPAGATION_ADM.START_PROPAGATION( propagation_name => 'prop1'); END; /
If running these procedures does not correct the problem, then run the STOP_PROPAGATION
procedure with the force
parameter set to true
, and restart propagation. For example:
BEGIN DBMS_PROPAGATION_ADM.STOP_PROPAGATION( propagation_name => 'prop1', force => true); END; / BEGIN DBMS_PROPAGATION_ADM.START_PROPAGATION( propagation_name => 'prop1'); END; /
When you stop a propagation with the force
parameter set to true
, the statistics for the propagation are cleared.