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.
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.
To replay off-line transaction logs, follow these steps:
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.
Shut down Replication Server.
Restart Replication Server in standalone mode, using the -M flag.
Log in to the Replication Server and execute the set log recovery command for each primary database you are recovering.
See “Setting log recovery for databases”.
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
Execute the allow connections command to allow Replication Server to accept connections only from other Replication Servers and from RepAgents in recovery mode.
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.
Load the database dump into the temporary primary database.
Load the first or next transaction log dump into the temporary primary database.
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.
Verify that RepAgent has replayed the transaction log of the temporary database.
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, or
Execute admin who_is_down.
If the RepAgent reports “down,” load the next transaction log.
Repeat steps 7 through 9 until all transaction logs have been processed.
You are now ready to resume normal replication from the primary database.
Shut down Replication Server, which is still in standalone mode.
Execute the following commands:
rs_zeroltm data_server, database
dbcc settrunc('ltm', 'valid')
You may need to execute rs_zeroltm to
clear the locator information.
Restart Replication Server in normal mode.
Restart RepAgent for both the primary database and RSSD using sp_start_rep_agent.
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. See “Determining database generation numbers”.
