After you have upgraded, 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). This 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 simply get the replicated data into the Replication inbound queue, you cannot rebuild the inbound queue 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:
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.x, 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:
Use isql to connect to the Server you are upgrading.
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.
