Recovering Messages from Truncated Primary Database Logs

Recover truncated messages from the primary database log by replaying off-line transaction logs.

1. Create a temporary database such that the sysusages tables are similar in both the original and the temporary databases.

   To do this, you must use the same sequence of create database and alter database commands when creating the temporary database as were used to create the original database.

2. Shut down Replication Server.
3. Restart Replication Server in standalone mode, using the -M flag.
4. Log in to the Replication Server and execute the set log recovery command for each primary database you are recovering.
   This command puts the Replication Server into loss detection mode for the databases. Replication Server logs a message similar to the following:

   Checking Loss for DS1.PDB from DS1.PDB
       date=Nov-01-1995 10:35am
       qid=0x01234567890123456789

5. Execute the allow connections command to allow Replication Server to accept connections only from other Replication Servers and from RepAgents in recovery mode.
   Note: If you attempt to connect to this Replication Server by automatically restarting RepAgent in normal mode with scripts, the Replication Server rejects the connection. You must restart RepAgent in recovery mode while pointing to the correct off-line log. This step allows you to resend old transaction logs before current transactions are processed.
6. Load the database dump into the temporary primary database.
7. Load the first or next transaction log dump into the temporary primary database.
8. Start the RepAgent for the temporary database in recovery mode:

   sp_start_rep_agent temp_dbname, 'recovery',
   'connect_dataserver', 'connect_database',
   'repserver_name', 'repserver_username',
   'repserver_password'

   where connect_dataserver and connect_database specify the original primary data server and database.

   RepAgent transfers data in the transaction log of the temporary recovery database to the original primary database. When RepAgent completes scanning the current transaction log, it shuts down.

9. Verify that RepAgent has replayed the transaction log of the temporary database by doing either one of:
   • Check the Adaptive Server log for the following message:

     Recovery of transaction log is complete. Please
     load the next transaction log dump and then start
     up the Rep Agent Thread with sp_start_rep_agent,
     with ‘recovery’ specified.

     and perform the appropriate actions.

   • Execute admin who_is_down.

     If the RepAgent reports “down,” load the next transaction log.

10. Repeat steps 7 through 9 until all transaction logs have been processed.

    You are now ready to resume normal replication from the primary database.

11. Shut down Replication Server, which is still in standalone mode.
12. You may need to execute rs_zeroltm to clear the locator information:

    rs_zeroltm data_server, database 
    dbcc settrunc('ltm', 'valid')

13. Restart Replication Server in normal mode.
14. Restart RepAgent for both the primary database and RSSD using sp_start_rep_agent.
15. If you have performed another recovery procedure since you performed the last database dump, you may need to change the database generation number after loading a transaction log dump.