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 cannot 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).
If messages are still in the online log at the primary database (which is unlikely), recover messages from the online database log.
If messages have been truncated from the online database log, recover the truncated messages from the database log.
In this procedure, you must load a previous database dump and transaction log dumps into a temporary recovery database. Then connect a RepAgent to that database to transmit the truncated log to the Replication Server. After the missing log records are recovered, you can restart the system using the regular primary database.
Using a temporary recovery database permits transaction recovery from clients that continued to use the primary database after its log was truncated.