Upgrading Adaptive Server in replication system

If you are upgrading Adaptive Server in your replication system, use the database upgrade procedure as follows.

1. Suspend transaction processing and replication system activities.

2. Drain transaction logs for primary databases.

3. Drain the RSSD transaction log.

4. Disable the secondary truncation point.

5. Upgrade Adaptive Server.

6. Restore Replication after upgrade.

Complete the following tasks before upgrading the Adaptive Servers in your replication system.

Suspend transaction activity in the databases and suspend replication.

1. Verify that the subscriptions you are creating with the create subscription command, with primary data in the databases being upgraded, have reached a “valid” state at the primary Replication Server.

   Do not upgrade while the above subscriptions are being created.

   Make sure no users create subscriptions for the data in the database you are upgrading until the upgrade procedure is finished.

2. Run rs_helproute in each Replication Server System Database (RSSD) being upgraded to determine the status of each RSSD.

   The status of all routes should be “Active.” See Chapter 6, “Managing Routes” in the Replication Server Administration Guide Volume 1, to resolve route problems.

3. Shut down the applications that are using the databases you are upgrading.

4. Use the admin who command in Replication Server to identify the existing Data Server Interface (DSI) connections to the data server being upgraded.

5. Suspend all DSI connections to non-RSSD databases you are upgrading by using the following command for each database:

   suspend connection to dataserver.database
   

6. Leave the DSI connections for the RSSDs running.

For each primary database you are upgrading, follow these steps to ensure that the Replication Server completely processes the pre-upgrade log.

1. Wait for all remaining transactions to be replicated.

2. Run this Replication Server command:

   admin who, sqm
   

   Find the entry that corresponds to the inbound queue for this database by looking for the Info field for the queue_number, queue_type entry. For an inbound queue, the queue type is 1. Note the last segment:block entry for the queue.

3. Open the queue dump file by executing the following Replication Server command, where file_name is the name of the dump file you will dump to:

   sysadmin dump_file, "file_name"
   

4. Create a dummy table to check that the Replication Server has received the latest log record written in the log. You can drop this table later on.

   create table dummy (c1 int, c2 char(255))
   go
   sp_setreptable dummy, true
   go
   begin tran
   go
   insert dummy values (1,'hello')
   go 10
   commit tran
   go
   

5. In the primary Replication Server, execute the admin who, sqm command until the last segment:block entry for the inbound queue changes.

6. Execute the following Replication Server command to dump the last block of the inbound queue to the dump file you created in step 3:

   sysadmin dump_queue, queue_number, queue_type, 
      last_seg, block, 1
   

   Use the queue_number, queue_type, last_seg, and block values found in the output of the admin who, sqm command in step 5.

7. Examine the dump file to make sure it contains the transaction corresponding to the inserts you performed in step 4 (you can use an editor to examine the file).

8. Repeat steps 5 through 7 until the transaction corresponding to the update is in the dump file. After draining the transaction logs, do not allow any other activity in the databases. If activity does occur, you need to redrain the transaction logs.

Manually drain the transaction log of each primary RSSD in the data server you are upgrading.

If Replication Server has routes to other Replication Servers, make sure that Replication Server processes all transactions in the RSSD transaction log before you upgrade the databases.

You can make sure the transaction log is completely processed by creating a replication definition in the primary Replication Server and then watching for it to appear in the replicate Replication Server RSSD. When the replication definition is in the replicate RSSD, the log is fully processed.

1. Log in to the primary Replication Server.

2. Create a temporary replication definition:

   create replication definition rep_def_name 
      with primary at dataserver.database 
      (column_a int) 
      primary key (column_a)
   

3. Log in to the replicate RSSD.

4. Execute the following query to see whether the replication definition has arrived from the primary RSSD:

   select * from rs_objects 
      where objname = "rep_def_name"
   

When the replication definition has arrived in the replicate RSSD, the RSSD transaction log has been drained.

When you upgrade a primary database, the Replication Agent must not be running and the secondary truncation point should be turned off for the duration of the upgrade.

1. Shut down the Replication Agents or make sure that dbcc logtransfer is not running for the databases that is being upgraded.

2. Shut down Replication Servers for the RSSDs you are upgrading.

3. In each primary database including RSSDs, execute the following commands to turn off the secondary truncation point:

   1> use database 
   2> go 
   1> dbcc settrunc ("ltm", "ignore") 
   2> go
   

   Repeat step 3 for each primary database and each primary RSSD.

For information on upgrading Adaptive Server, see the Adaptive Server Enterprise Installation Guide for your platform.

1. Zero out the locator in the RSSD for each replicated primary.

   Using isql, connect to the RSSD and execute the following commands:

   1> use RSSD 
   2> go 
   1> rs_zeroltm dataserver, RSSD 
   2> go
   

2. Set the secondary truncation point to “valid” in each primary database. Using isql, connect to the replicated primary database, and execute the following commands:

   1> use database
   2> go
   1> dump tran database with truncate_only
   2> go
   1> dbcc settrunc("ltm","valid")
   2> go