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.
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 primary database for recovery, you must change the database generation number, as instructed in the recovery procedure you are using.
The maximum value for the database generation number is 65,535. Sybase recommends that you avoid incrementing the number to high values unless absolutely necessary.
If you want to reset the database generation number, you must rebuild the replication environment. Rebuilding the environment includes deleting the connection to the primary database where you want to reset the database generation number, recreating the connection, and then rebuilding the replication configuration of the primary database.
In addition to Adaptive Server, you can reset database generation numbers for all supported non-ASE databases acting as the primary database. See the Replication Server Heterogeneous Replication Guide for supported primary databases.
Resetting primary database generation number
In this procedure, the primary database refers to the primary database where you want to reset the database generation number.
At the replicate Replication Server, drop all subscriptions that reference replication definitions and publications defined for the connection to the primary database.
Drop all publications referenced by the subscriptions you dropped in step 1.
Drop all articles referenced by the publications you dropped in step 2.
In the primary Replication Server, drop all replication definitions for the primary database connection.
In the primary Replication Server, drop the connection to the primary database, and all connections to replicate databases that subscribe to the primary database.
Set the database generation number to 0 on the primary database:
In Adaptive Server:
dbcc settrunc(‘ltm’, ‘gen_id’, 0)
In Replication Agent for IBM DB2 UDB on UNIX and Windows, Microsoft SQL Server, and Oracle:
pdb_gen_id 0
In the primary Replication Server, create a new connection to the primary database, and create connections to the replicate databases.
Recreate all the replication definitions, publications, articles, and subscriptions you dropped. See “Setting up a replication environment,” in Chapter 3, “Managing Replication Server with Sybase Central” in the Replication Server Administration Guide Volume 1.
