Each primary database in a replication system includes a database generation number. This number is stored both in the database and in the RSSD of the Replication Server that manages the database.
Any time you load a database for recovery, you may be required to change the database generation number, as instructed in the recovery procedure you are using. This section explains this step.
RepAgent for a primary database places the database generation number in the high-order 2 bytes of the qid that it constructs for each log record it passes to the Replication Server.
The remainder of the qid is constructed from other information that gives the location of the record in the log and also ensures that the qid increases for each record passed to Replication Server.
The requirement for increasing qid values allows Replication Server to detect duplicate records. For example, when a RepAgent restarts, it may resend some log records that Replication Server has already processed. If Replication Server receives a record with a lower qid than the last record it processed, it treats the record as a duplicate and ignores it.
If you are restoring a primary database to an earlier state, increment the database generation number so that the Replication Server does not ignore log records submitted after the database is reloaded. This step applies only if you are using the procedures described in “Loading a primary database from dumps” or in “Loading from coordinated dumps”.
If you are replaying log records, increment the database generation number only if RepAgent previously sent the reloaded log records with the higher generation number. This situation arises only if you have to restore the database and log to a previous state for the first failure and then later replay the log due to a second failure.
WARNING! Only change the database generation number as part of a recovery procedure. Changing the number at any other time can result in duplicate or missing data at replicate databases.
When you reload a database dump, the database generation number is included in the restored database. Since the database generation number is also stored in the RSSD of the Replication Server that manages the database, you may need to update that number so that it matches the one in the restored database.
However, when you reload a transaction log, the database generation number is not included in the restored log. For example, assume the following operations have occurred in a database:
Operation |
Database generation number |
|---|---|
database dump D1 |
100 |
transaction dump T1 |
100 |
dbcc settrunc('ltm', 'gen_id', 101) |
101 |
transaction dump T2 |
101 |
database dump D2 |
101 |
If you reload database dump D1, database generation number 100 is restored with it. If you reload transaction dump T1, the generation number remains at 100. After transaction dump T2, the generation number remains at 100, because reloading transaction dumps does not alter the database generation number. In this case, you need to change the database generation number to 101 using the dbcc settrunc command before having RepAgent scan transaction dump T2.
However, if you load database dump D2 before resuming replication, you do not have to alter the database generation number, since the number 101 is restored.
