Recovering Messages from Off-line Database Logs

Recover messages from off-line logs after a partition failure.

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.

  1. Restart Replication Server in standalone mode, using the -M flag.
  2. Rebuild the stable queues. Log in to the Replication Server, and enter:
    rebuild queues
  3. Inspect the Replication Server logs at each site for “Checking Loss” messages and use the date and time in the error log messages to determine which dumps to load.
  4. Enable RepAgent for a temporary recovery database:
    sp_config_rep_agent temp_dbname, 'enable', \
    'rs_name', 'rs_user_name', 'rs_password'

    See Replication Server Administration Guide Volume 1 > Manage RepAgent and Support Adaptive Server > Set up RepAgent.

  5. Load the database dump and the first transaction log dump in to a temporary recovery database.
  6. 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.

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

  8. 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.
  9. 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.
  10. 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.

  11. Restart the Replication Server in normal mode.
  12. Restart RepAgent for the original primary data server and database in normal mode.
Related concepts
Rebuild Queues Online
Determine Which Dumps to Load
Determine Database Generation Numbers
Loss Detection After Rebuilding Stable Queues