Installation Guide Adaptive Server Enterprise for IBM RISC System/6000 AIX

Home

Installation Guide Adaptive Server Enterprise for IBM RISC System/6000 AIX

Chapter 8 Upgrading Sybase Servers

Preparing to upgrade servers with replicated databases

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.

Suspending transaction processing and replication activities

To suspend replication of and transaction activity in the databases:

Verify that subscriptions that are being created by the create subscription command, with primary data in the databases being upgraded, have reached the "valid" state at the primary Replication Server before you begin the upgrade. Use the check subscription command to find the "valid" state.
Defer upgrade while the subscriptions are being created so that Replication Server does not interfere with the upgrade process by accessing the database being upgraded.
Make sure that no users create subscriptions for data in the database you are upgrading until the upgrade procedure is finished.
Execute rs_helproute in each Replication Server System Database (RSSD) being upgraded.
The status of all existing routes should be "Active". If any route is not active, resolve the route before continuing. See the Replication Server documentation for help in diagnosing and fixing the problem with the route, and then go to step 3.
Shut down all applications that use the databases you are upgrading.
Use the admin who command in Replication Server to find the existing Data Server Interface (DSI) connections to the data server being upgraded.
Suspend all DSI connections to the non-RSSD databases you are upgrading by entering the following command in Replication Server for each database:
```
1> suspend connection to dataserver.database2> go
```
Leave the DSI connections to the RSSD databases running.

Draining the transaction logs for primary databases

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

To drain the transaction logs:

Wait for all remaining transactions to be replicated.
Run the following Replication Server command:
```
1> admin who, sqm
2> go
```
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 Seg.Block entry for the queue.
Open a queue dump file by executing the following Replication Server command:
```
1> sysadmin dump_file, "file_name"
2> go
```
where file_name is the name of the file to which you will dump the queue.
Use isql to update one row in a single replicated table in the primary database:
```
1> update table set column = column 
2> where key = unique_value3> go
```
The update command helps to track whether all modifications to the replicated database have been sent to the Replication Server.
In Replication Server 10.1 or later, choose a table that does not use the replicate minimal columns clause, or use the alter replication definition command...replicate all columns command to change the replication definition before updating the row. If you alter the replication definition, be sure to change it back after you complete this upgrade procedure.
In the primary Replication Server, execute the admin who, sqm command until the last segment:block entry for the inbound queue changes.
Execute the following Replication Server command to dump the last block of the inbound queue to the dump file you created in step 3:
```
1> sysadmin dump_queue, queue_number,
2> queue_type, last_seg, block, 1
3> go
```
Use the queue_number, queue_type, last_seg, and block values found in the output of the last admin who, sqm command.
Examine the dump file to make sure it contains the transaction that corresponds to the update you performed in step 4. (You can use Notepad to examine the file.)
Repeat steps 5-7 until the transaction that corresponds to the update is in the dump file.
Log into the Replication Server and suspend the Log Transfer connection from that database:
```
1> suspend log transfer from server.database
2> go
```
If you are using Rep Agent, log into the ASE server, and stop the Rep Agent:
```
1> use database
2> go
```
```
1> sp_stop_rep_agent database
2> go
```
If you are using LTM, shut down the LTM.

After draining the transaction logs, do not allow any other activity in the databases. If activity does occur, you will need to redrain the logs.

Draining the RSSD Transaction Log

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

To see whether the transaction log has been processed completely, create a replication definition in the primary Replication Server and then watch for it to appear in the replicate Replication Server's RSSD. When the replication definition is in the replicate RSSD, you can assume that the log is processed fully.

To ensure that the RSSD log is processed:

Log into the primary Replication Server and create a temporary replication definition:
```
1> create replication definition rep_def_name2> with primary at dataserver.database3> (column_a int)
4> primary key (column_a)
5> go
```
The data server and database names must be valid, but the replication definition does not have to reference an actual table.
Log into the replicate RSSD (not the primary RSSD) and execute the following query to find out if the replication definition has arrived from the primary RSSD:
```
1> select * from rs_objects 
2> where objname = "rep_def_name"
3> go
```
If this select statement returns rows, the last replication definition created in step 1 has been sent successfully to the replicate RSSD. This means that the transaction log has been drained.
Log into the replicate Replication Server and suspend the Log Transfer connection from the primary RSSD:
```
1> suspend log transfer from server.database
2> go
```
If you are using Rep Agent, log into the ASE server, and stop the Rep Agent:
```
1> use database2> go
```
```
1> sp_stop_rep_agent database
2> go
```
If you are using LTM, shutdown the LTM.

Disabling the secondary truncation point

When you upgrade a primary database, the Rep Agent or the Log Transfer Manager (LTM) must not be running, and the Secondary truncation point should be turned off for the duration of the upgrade. The Rep Agent or Log Transfer Manager should already be shutdown (from the previous steps).

For each primary database and replicated RSSD, disable the secondary truncation point:

If this is a replicated RSSD, log into the Replication Server of the RSSD, and issue:
```
1> sysadmin hibernate_on, 'Replication
Server'
2> go
```
Disable the secondary truncation point in the Adaptive Server database that is being upgraded by issuing:
```
1> use database
2> go
```
```
1> dbcc settrunc('ltm', 'ignore')
2> go
```
If the dbcc settrunc command fails, make sure that the Rep Agent or LTM are not running. When the Rep Agent and LTM are disabled, repeat this step.


	Expand Search