If the origin_qid values stored in a data server or the rs_exceptslast table is modified by mistake, non-duplicate transactions may be ignored, or duplicate transactions may be reapplied.
If you suspect that this is happening in your system, check the stored values and compare them with the transactions in the database’s stable queue to determine the validity of the values. If the values are wrong, you must modify them directly.
The Data Server Interface (DSI) records the last transaction committed or written into the exceptions log so that it can detect duplicates after a system restart. Each transaction is identified by a unique origin database ID and an origin queue ID that increases for each transaction.
The last transaction committed from each origin database is recorded on a data server through execution of the function strings defined for the data server’s function-string class. For the default function-string class, rs_sqlserver_function_class, this is done in the function string of a commit command, that is, the rs_commit function. The function-string class of every data server must support the rs_get_lastcommit function which returns the origin_qid and secondary_qid for each origin database. The secondary_qid is the ID of the queue used for subscription materialization or dematerialization.
The origin_qid and secondary_qid for the last transaction written into the exception log from each origin is recorded in the rs_exceptslast table in the Replication Server System Database (RSSD). However, transactions logged explicitly by the sysadmin log_first_tran command are not recorded in this table. These transactions are logged, but they are not skipped.
When a data server interface is started or restarted, it gets the origin_qid returned by the rs_get_lastcommit function and the one stored in the rs_exceptslast table. It assumes that any transaction in the queue with an origin_qid less than the larger of these two values is a duplicate and ignores it.