The steps you need to take in the recovery process depend on whether you leave the transaction log untouched on incremental backup in your backup process. If your backup operation deletes or renames the transaction log, you may have to apply changes from several transaction logs. If your backup operation leaves the transaction log untouched, you need to use only the online transaction log in recovery.
When you have multiple transaction logs, it is possible that transactions may span transaction logs. You must apply the transaction logs in the correct order when recovering; otherwise, transactions that span multiple transaction logs are rolled back. You can specify the -ad database server option if you want the database server to determine the correct order in which to apply the transaction logs.
For more information, see Recovering from multiple transaction logs.
For more information about the backup types discussed here, see Designing backup procedures.
To recover from media failure on the database file
Make an extra backup copy of the current transaction log. The database file is gone, and the only record of changes since the last backup is in the transaction log.
Create a recovery directory to hold the files you use during recovery.
Copy the database file from the last full backup to the recovery directory.
Apply the transactions held in the backed up transaction logs to the recovery database. You can use either of the following methods to do this.
If you want to apply each transaction log manually, for each log file, in chronological order do the following:
dbeng11 database-name.db -a log-name.log |
The database server shuts down automatically once the transactions are applied.
Apply the transactions from the online transaction log to the recovery database.
dbeng11 database-name.db -a log-name.log |
If you want the database server to determine the correct order of the transaction logs and apply them automatically, do the following:
dbeng11 database-name.db -ad log-directory |
The database server shuts down automatically once the transactions are applied.
Perform validity checks on the recovery database.
Make a post-recovery backup.
Move the database file to the production directory.
Allow users to access the production database.
Send feedback about this page via email or DocCommentXchange | Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0 |