Recovery from Truncated Primary Database Logs

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).

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), 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.

Note: Use the temporary database exclusively for recovering messages. Any modification to the database prevents you from loading the next transaction log dump. Also limit the activity on the original primary database so that the recovery can be completed before the transaction log on the original primary database must be dumped and truncated again.