Previous |
Next |
Sometimes, a destination queue in an Oracle Streams replication environment stops accepting propagated changes. The destination queue might stop accepting changes if, for example, the database that contains the queue goes down, there is a problem with the destination queue, the computer system running the database that contains the queue goes down, or for some other reason.
When a destination is unavailable in a replication environment that uses capture processes, captured changes that cannot be sent to a destination queue remain in the source queue. The source queue size increases and, eventually, the changes spill out of the buffered queue memory onto disk. When this happens, the performance of the Oracle Streams replication environment suffers.
To determine whether a large number of captured changes are spilling to disk, follow the instructions in "Viewing Statistics for a Capture Process". The Queue Statistics graph shows the current number of changes spilling to disk in the capture process's queue.
If your replication environment uses capture processes to capture changes, then you can set two capture process parameters to manage an unavailable destination automatically. The split_threshold
and merge_theshold
capture process parameters control whether Oracle Streams performs split and merge operations automatically. When these parameters are set to specify automatic split and merge, Oracle Scheduler jobs monitor the streams flowing from the capture process. When an Oracle Scheduler job identifies a problem with a stream, the job submits a new Oracle Scheduler job to split the problem stream off from the other streams flowing from the capture process. Other Oracle Scheduler jobs continue to monitor the stream, and, when the problem is corrected, an Oracle Scheduler job merges the stream back with the other streams.
When the split_threshold
capture process parameter is set to infinite
, automatic splitting is disabled. When the split_threshold
parameter is not set to infinite
, automatic splitting is enabled. Automatic splitting only occurs when communication with an apply process has been lost for the number of seconds specified in the split_threshold
parameter. For example, communication with an apply process is lost when an apply process becomes disabled or a destination database goes down.
Note: Automatic splitting does not occur when one stream is processing changes slower than other streams. In this situation, it is usually best to reconfigure the environment so that the slower stream uses a different capture process than the other streams.
To manage the unavailable destination:
Ensure that the following parameters are set properly for the capture process to enable automatic split and merge:
split_threshold
: Ensure that this parameter is not set to infinite. The default setting for this parameter is 1800
.
merge_threshold
: Ensure that this parameter is not set to a negative value. The default setting for this parameter is 60
.
Monitor the DBA_STREAMS_SPLIT_MERGE
view periodically to check whether an automatic split and merge operation is in process.
When an automatic split occurs, certain components, such as the capture process, queue, and propagation, are cloned, and each is given a system-generated name. The DBA_STREAMS_SPLIT_MERGE
view contains the name of each cloned component, as well as other information about the split and merge operation.
If a split and merge operation is in process, then correct the problem with the destination. The problem is corrected when the apply process at the destination database can accept changes from the cloned capture process.
If the cloned capture process is disabled, then start the cloned capture process. See "Starting and Stopping a Capture Process"
Oracle Streams Replication Administrator's Guide for detailed instructions about using split and merge