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_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.
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 database
2> go
```
```
1> sp_stop_rep_agent database
2> go
```
If you are using LTM, shutdown the LTM.