After upgrade, you will no longer be able to scan any part of the transaction log that existed before the upgrade, so you must follow the following process if your server contains replicated primary databases (this includes replicated RSSDs). The following procedure will help to ensure that all replicated data from a replicated database has made it safely to the replicate database.
WARNING! It is not sufficient to just get the replicated data into the Replication inbound queue, because the inbound queue cannot be rebuilt after the upgrade.
The procedures described here do not upgrade Replication Server itself. For information on upgrading Replication Server, see your Replication Server documentation.
The database upgrade procedure consists of the following activities:
Suspending transaction processing and replication activities.
Draining transaction logs for primary databases.
Draining the Replication Server System Database (RSSD) log.
Disabling the log truncation point.
After upgrading to version 12.5, complete the post-upgrade tasks to reenable database replications functions.
For more information, see the Replication Server Reference Manual and the Replication Server System Administration Guide.
WARNING! As a safeguard, perform a dump database and a dump transaction before executing the procedures in the following sections.
To determine whether your existing server contains replicated databases:
Connect to the Server you are upgrading via isql.
Run the following command in each database (including system databases):
1> dbcc gettrunc 2> go
If the command returns “1” for “ltm_trunc_state” in any database, replication is enabled in that database.
