Filter
Top Products
APPENDIX B Upgrading Servers with Replicated Databases
Installation Guide 133
2> go
12 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:
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 does not have to 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.