Managing recapture avoidance issues in bidirectional replication

In configurations with many bidirectional Q subscriptions, a number of options are available to lessen the possible performance impact of signals that are inserted into the IBMQREP_SIGNAL table to prevent recapture of transactions.

About this task

About this task

To avoid recapture, by default the Q Apply program inserts a P2PNORECAPTURE signal for each transaction that it applies. The signals are inserted at the Q Capture server that is shared by the Q Apply program. When Q Capture reads the signals in the log, it ignores these transactions.

To avoid a potential performance impact in configurations with many bidirectional Q subscriptions, you have several options:

With a high-volume transactional workload, lower the value of the Q Capture pruning_interval parameter. The default value of 5 minutes might cause pruning to fall seriously behind (more signals are inserted than can be pruned). A value of 10 seconds is reasonable: It does not cause any noticeable overhead, yet allows Q Capture to keep up with pruning.
Specify that the programs use the IBMQREP_IGNTRAN table to avoid recapture. This method tells the Q Capture program to automatically ignore any changes that come from the Q Apply program.
Start the Q Apply program with the insert_bidi_signal=n startup parameter. This option is not valid for unidirectional or peer-to-peer replication. Use this setting only for bidirectional replication.

Use the following guidelines to determine which method to use to avoid recapture:

Table 1. Recapture avoidance methods for different bidirectional replication configurations
Configuration	Recapture avoidance method
Multiple bidirectional configurations between two servers, or a combination of bidirectional, unidirectional, and peer-to-peer configurations	You must accept the default method The default method of signal inserts ensures that all changes are propagated correctly between servers. Closely monitor pruning performance and adjust the value of pruning_interval if necessary. If you start with a pure, two-server bidirectional topology but plan to later add branching unidirectional or peer-to-peer configurations, you should also accept the default method of recapture avoidance.
Pure, two-server bidirectional configuration	Performance can be improved by using the IBMQREP_IGNTRAN table to avoid recapture If you use the IBMQREP_IGNTRAN table method, do not later add branching unidirectional or peer-to-peer configurations to the bidirectional configuration.