How the Roll Forward (Restore) Operation Works
Performing a roll forward of a database overwrites the current contents of the database being recovered.
To perform a roll forward, you must be the DBA for the database or have the operator privilege.
When you roll forward (restore) a database, the database is locked to prevent errors from occurring. If the database is busy, the roll forward operation waits for the database to be free before recovering it. (If you specify the wait [+w] option, the rollforwarddb operation pauses until all users have left the database. If you do not specify the wait option, you get a message that the database is in use.)
If the target checkpoint was taken online (when the database was in use), the roll forward operation does the following:
• Restores the database from the checkpoint location to the database location.
• Applies the log records in the dump location to the database, which restores the database to the state when the checkpoint began. The log records contain the transactions that were in progress when the checkpoint was taken.
This step is not performed when restoring a database from an offline checkpoint because there were no transactions in progress during an offline checkpoint.
• Applies the journal records to the database, if the database is journaled.
Note: A roll forward can write Compensation Log Records (CLRs) to the transaction log file while executing the rollback phase of a roll forward recovery. This happens rarely, only if incomplete transaction histories are written to the journals. This is an unlikely condition except when the transaction log file is lost (or, if running with dual logging, when both copies are lost). In this case, it is possible for journal files to grow in size as a consequence of performing a roll forward.