If insert or update operations in the primary database are not being replicated, and if you do not find any errors in the Replication Agent system log or trace log, the most likely problem is that the values of the origin queue ID (qid) sent to the primary Replication Server are lower than previous values of the qid, and therefore, the new operations are being ignored by the primary Replication Server.
To correct the problem of incorrect qid values
Turn on tracing for the LTITRACELTL trace flag.
You can view Replication Agent LTL output by examining the contents of the LTITRACELTL.log file.
Log in to the primary Replication Server and use the admin who, sqm command to determine if any duplicate operations are in the inbound queue of the primary Replication Server.
If you find duplicate operations in the inbound queue of the primary Replication Server, then Replication Agent is re-sending operations to the primary Replication Server as part of a recovery process. Finding duplicate operations indicates that the value of the Replication Agent origin queue ID is not the problem.
If you find no duplicate operations in the inbound queue of the primary Replication Server, continue this procedure to reset the qid value.
Log in to the Replication Agent administration port using the following command:
isql -Uusername -Ppassword -Sinst_name
where username is the Replication Agent administrative user ID, password is the corresponding password, and inst_name is the name of the Replication Agent instance.
Use the Replication Agent quiesce command to bring the Replication Agent instance to the Admin state.
quiesce
Use the Replication Agent ra_locator command to set the value of the LTM Locator stored by the Replication Agent instance to all zeros.
ra_locator zero
Log in to the RSSD of the primary Replication Server and execute the rs_zeroltm stored procedure.
rs_zeroltm PDS, PDB
where PDS is the name of the primary data server and PDB is the name of the primary database, as specified in the create connection command in the primary Replication Server.
Restart replication by using the Replication Agent resume command.
resume
After the value of the LTM Locator is set to all zeros in both the Replication Agent transaction log and the RSSD of the primary Replication Server, Replication Agent starts scanning the transaction log.
Trigger-based Replication Agents (for Informix, Microsoft SQL Server, and Oracle) start scanning the transaction log from the beginning of the log. All operations in the transaction log are sent to the inbound queue of the primary Replication Server.
Log-based Replication Agents (for DB2 Universal Database) start scanning the transaction log at the end of the log. Any previous transactions are not sent, including transactions that may not have been sent before. In that event, a loss of data may occur. For more information on transaction log positioning, see “Handling repositioning in the log”.
