The 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 at a data server by executing the function strings defined for the data server’s function-string class. For the system-defined classes, this is done in the function string for a commit command, that is, the rs_commit function. Every function-string class supports 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 exceptions log from each origin is recorded into the rs_exceptslast system table. However, transactions logged explicitly by the sysadmin log_first_tran command are not recorded in this system table. These transactions are logged, but they are not skipped.
When a DSI is started or restarted, it gets the origin_qid returned by the rs_get_lastcommit function and the one stored in the rs_exceptslast system 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.
If the origin_qid values stored in a data server or the rs_exceptslast system table are 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 values stored 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.
Refer to the Replication Server Troubleshooting Guide for details on how to dump transactions in a queue.
