This section describes how to recover from failures caused by truncating a primary transaction log before Replication Server has received the messages.
This situation typically occurs if RepAgent, a Replication Server (managing a primary database), or a network between them is down for a long time and RepAgent or Replication Server is unable to read records from the transaction log. The secondary truncation point cannot be moved, which prevents Adaptive Server from truncating the log and causes the transaction log of the primary database to fill up. You can then remove the secondary truncation point by executing sp_stop_rep_agent followed by dbcc settrunc (ltm, ignore).
When a failed component returns to service, messages are missing at the Replication Server. Depending on the status of the lost messages, use one of the following procedures:
If messages are still in the online log at the primary database (which is unlikely), see “Message recovery from the online database log”.
If messages have been truncated from the online database log, see “Truncated message recovery from the database log”.
