Draining the RSSD Transaction Log

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

To ensure that 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 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:

  1. Log in to the primary Replication Server and create a temporary replication definition:
    1> create replication definition rep_def_name
    2> with primary at dataserver.database
    3> (column_a int)
    4> primary key (column_a)
    5> go
    The data server and database names must be valid, but the replication definition need not reference an actual table.
  2. Log in to 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.
  3. Log in to the replicate Replication Server and suspend the log transfer connection from the primary RSSD:
    1> suspend log transfer from server.database
    2> go
  4. If you are using Rep Agent, log in to the Adaptive Server, and stop the Rep Agent:
    1> use database
    2> go
    1> sp_stop_rep_agent database
    2> go
  5. If you are using LTM, shut down the LTM.
  6. If this is a replicated RSSD, log in to the Replication Server of the RSSD and issue:
    1> sysadmin hibernate_on, 'Replication_Server_name'
    2> go