Q Replication and Event Publishing

Improving performance in bidirectional replication with the IBMQREP_IGNTRAN table

You can use the Q Capture program's ability to ignore specified transactions to improve performance in a pure, two-server bidirectional configuration.

About this task

To avoid the recapture of transactions, by default the Q Apply program inserts P2PNORECAPTURE signals into the IBMQREP_SIGNAL table 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.

When there are many bidirectional Q subscriptions, the number of signal inserts can affect replication performance. To avoid this, you can 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. You also start the Q Apply program with the insert_bidi_signal=N startup parameter.

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. 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.

Procedure

To use the IBMQREP_IGNTRAN table to avoid recapture in bidirectional replication:

Insert an identifier for the Q Apply program into the IBMQREP_IGNTRAN table at the server that is shared by the Q Apply program and Q Capture program in the bidirectional configuration. Use the following SQL depending on your operating system:
z/OS®
```
insert into schema.IBMQREP_IGNTRAN (
    PLANNAME,
    IGNTRANTRC
) values (
    'qapply_plan',
    'N' );
```
Where schema is the schema that is shared by the Q Apply program and Q Capture program at the server, and qapply_plan is the plan name for the Q Apply program, for example ASNQA910 for a Version 9.1 Q Apply program.
Linux, UNIX, Windows
```
insert into schema.IBMQREP_IGNTRAN (
    AUTHID,
    IGNTRANTRC
) values (
    'qapply_authid',
    'N' );
```
Where schema is the schema shared by the Q Apply program and Q Capture program at the server, and qapply_authid is the authorization ID that started the Q Apply program.
To use the IBMQREP_IGNTRAN table option, the Q Apply program's authorization ID must be unique and not shared by other applications, except for the Q Capture program. Otherwise, the Q Capture program will incorrectly ignore transactions from these other applications as well. On z/OS, this situation is rare because plan names are unique. However, on Linux, UNIX, and Windows it is not unusual to run the Q Apply program under the same authorization ID as other applications.

If Q Apply was migrated to Version 10.1 on z/OS: The Q Apply plan name for Version 10.1 on z/OS changed to ASNQA101 from ASNQA910. To ensure that transactions from the Version 10.1 Q Apply program are ignored, after Q Apply is migrated to Version 10.1 you must enter the new ASNQA101 plan name in the IBMQREP_IGNTRAN table and then either reinitialize the Q Capture program or stop and start Q Capture so that it reads the new plan name. As a safeguard, you can put both the ASNQA101 and ASNQA910 plan names in IBMQREP_IGNTRAN.

The Q Capture program ignores all replicated transactions that come from the specified Q Apply plan name or authorization ID, but continues to read and process signals from Q Apply in the IBMQREP_SIGNAL table.
When you start the Q Apply program, specify the insert_bidi_signal=n startup parameter. The short form syntax is INS=N.
Optional: For improved performance when you use insert_bidi_signal=n, ensure that the value of the IGNTRANTRC column in the IBMQREP_IGNTRAN table is set to N (no tracing). A value of N, the default, prevents the Q Capture program from inserting a row into the IBMQREP_IGNTRANTRC table for each transaction that it does not recapture and reduces maintenance overhead on the table.

Send your feedback | Information roadmap | The Q+SQL Replication Forum

Last updated: 2013-10-25