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:
-
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.
-
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.
-
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
-
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
-
If you are using LTM, shut down the LTM.
-
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