Replication fails to start after resuming standby connection

When replication fails to start after you resume the standby connection in Replication Server, there are two probable causes:

The standby DSI thread does not recognize the “enable replication” marker.
The secondary truncation point was moved while there was an open transaction in the stable queue.

Problem with enable replication marker

If the Replication Server standby database connection is resumed before the Mirror Replication Agent is resumed, the standby DSI thread may not recognize the “enable replication” marker in the inbound queue. In that event, the standby DSI continues to ignore messages in the inbound queue, waiting for the marker to appear. The following symptoms indicate this problem:

Mirror Replication Agent processes the transaction log and sends LTL to the Replication Server for distribution, but Replication Server sends no transactions to the standby database after the standby connection is resumed.
The admin logical_status command reports the following standby connection state:
```
Active/Waiting for Enable Marker
```
The admin who, dsi command reports the following standby DSI Ignoring Status:
```
Ignoring
```
The standby database row in the RSSD rs_databases table contains a value of 0x8 in the dist_status column, and a non-zero value in the enable_seq column.

To avoid this problem, always resume replication in the Mirror Replication Agent before you resume the Replication Server standby connection.

To correct the enable replication marker problem

Suspend the standby connection in Replication Server.
Suspend the Mirror Replication Agent.
Purge all open transactions in the Replication Server stable queue.

See the Replication Server Reference Manual for information about the sysadmin purge_all_open and sysadmin purge_first_open commands.
Resume the Mirror Replication Agent.
Resume the standby connection in Replication Server.

Problem with truncation point moved

If the secondary truncation point moves while an open transaction remains in the Replication Server stable (inbound) queue, no transactions are sent to the standby database. When this occurs:

Replication will not start, because Replication Server will not send any new transactions to the standby database until it receives operations to complete an open transaction.
Eventually, the stable queue will run out of space, because Replication Server will not send any transactions after you resume replication, and new transactions arriving in the stable queue will not be processed and deleted.

This problem may occur under the following conditions:

You suspend the Mirror Replication Agent after a transaction begin record is processed, but before the corresponding commit or abort record is processed, and then move the secondary truncation point (for example, using pdb_init move_truncpt).
The primary database goes offline after a transaction begin record is written to the mirror log device, but before the corresponding commit or abort record is written, triggering a failover to the standby database and requiring the primary database to be re-materialized.

To avoid this problem, do not move the secondary truncation point while an open transaction remains in the stable queue.

If you need to re-initialize the primary database, in preparation for re-initializing the Mirror Replication Agent, do not move the secondary truncation point.

To correct the moved truncation point problem

Purge all open transactions in the stable queue before resuming the Replication Server standby connection.

See the Replication Server Reference Manual for information about the sysadmin purge_all_open and sysadmin purge_first_open commands.

If the secondary truncation point must be moved (for example, when the primary database is re-materialized in a failback procedure), you must purge all open transactions in the stable queue before resuming the standby connection.