Message recovery from off-line database logs

If the online log does not contain all the data needed to recover, you must load an older version of the primary database into a separate database and start RepAgent for the database. Although RepAgent is accessing a different database, it submits messages as if they were from the database whose messages you are recovering.

To recover messages from off-line logs after a partition failure:

Restart Replication Server in standalone mode, using the -M flag.

Log in to the Replication Server, and enter:
```
rebuild queues
```
See “Rebuilding queues online” for a description of this process.
Inspect the Replication Server logs at each site for “Checking Loss” messages.

See “Determining which dumps to load” for background and details on examining these messages.
Use the date and time in the error log messages to determine which dumps to load.
Enable RepAgent for a temporary recovery database, using the sp_config_rep_agent system procedure.
```
sp_config_rep_agent temp_dbname, 'enable', \
'rs_name', 'rs_user_name', 'rs_password'
```
See “Setting Replication Server configuration parameters” on page 92 in the Replication Server Administration Guide Volume 1 for information about configuring RepAgent.
Load the database dump and the first transaction log dump in to a temporary recovery database.
Start RepAgent in recovery mode for the temporary database:
```
sp_start_rep_agent temp_dbname, 'recovery', \
'connect_dataserver', 'connect_database', \
'rs_name', 'rs_user_name', 'rs_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 transaction log, it shuts down.
Verify that RepAgent has replayed the transaction log of the temporary database. Use either of these methods:
- Check the Adaptive Server log for a message similar to the following:
```
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.
```
  Then, perform the appropriate actions.
- From Adaptive Server, execute the sp_help_rep_agent system procedure for recovery:
```
sp_help_rep_agent dbname, 'recovery'
```
  This procedure displays RepAgent’s recovery status. If the recovery status is “not running” or “end of log,” then recovery is complete. You can load the next transaction log dump. If the recovery status is “initial” or “scanning,” either the log has not been replayed, or the replay is not complete.
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”.
If there are more transaction log dumps to load, repeat the following three steps for each dump:
1. Load the next transaction log dump. (Be sure to load the dumps in the correct order.)
2. Restart RepAgent in recovery mode.
3. Watch the Adaptive Server log for the completion message or use sp_help_rep_agent.
Check the Replication Server logs for loss detection messages.

No losses should be detected unless you failed to load the database to a state old enough to retrieve all of the messages.

See “Loss detection after rebuilding stable queues” for background and details.
Restart the Replication Server in normal mode.
Restart RepAgent for the original primary data server and database in normal mode.