|
|
|
To recover a database from checkpoints and journals or from checkpoints only, you use the roll forward operation. This operation lets you recover the following:
|
|
|
Performing a roll forward of a database overwrites the current contents of the database being recovered.
When you roll forward 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 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:
Because there were no transactions in progress during an offline checkpoint, this step is not performed when restoring a database from an offline checkpoint.
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.
To perform a roll forward, you must be the DBA for the database or have the operator privilege.
|
|
|
In VDBA, to roll forward a database, use the Roll Forward DB dialog, invoked by the Database Rollforward DB menu command. For the detailed steps for performing this procedure, seethe Procedures section of online help for VDBA. See the Recovering a Database from Checkpoints topic.
To use a system command to accomplish this task, use rollforwarddb command. For more information, see the Command Reference Guide.
|
|
|
To recover a specific database from the last checkpoint and journal, where both the checkpoints and journals are stored online, select the default options in the Roll Forward DB dialog.
|
|
|
To recover a non-journaled database from the last checkpoint, enable the From Last Checkpoint check box in the Roll Forward DB dialog.
|
|
|
To recover a database whose checkpoints are on tape, mount the tape reel containing the checkpoints. Select the default options in the Roll Forward DB dialog and also specify the tape drive in the From Tape Device edit control.
The checkpoint is read from the tape and the journal files are applied, if the database is journaled, to bring your database up to date.
|
|
|
To roll forward a multi-location database to disk in parallel, issue the rollforwarddb command the #m flag followed by the number of parallel restores to be run.
For example, to restore two data locations at a time from the II_CHECKPOINT location, the command is as follows:
rollforwarddb #m2 dbname
|
|
|
To roll forward a multi-location database from tape in parallel, specify the devices to be used in the From Tape Device edit control. For example, the following tape device can be specified:
/dev/rmt/0m,/dev/rmt/1m
This restores one location per tape—the first location can be restored from device 0m; the second location can be restored from device 1M. The third location can be restored from whichever device is finished first. The remaining locations can be restored from the next free device. The operator is prompted to insert the numbered tape into the free device.
Some points to be aware of when performing parallel roll forward from tape in UNIX include:
|
|
|
You can specify that only certain tables are recovered during a roll forward database operation. (Journals of tables in the database must be enabled.) When doing table-level recovery, you can optionally move the table to a new location.
Note: The database must be extended to the new locations before the rollforward.
In the Roll Forward DB dialog, some of the available options that relate to specifying tables include:
Note: Table recovery is not allowed if structural changes have been made to the table after the checkpoint (that is, if you have modified the table, created indexes or altered the number of columns in the table).
|
|
|
If a user makes a serious error in a table that is being journaled, the changes can be retracted. Use roll forward to restore the database up to the beginning of the transaction in which the error occurred.
For example, to restore a database from the previous checkpoint to its condition at 8:00 A.M. on August 17, 1998, specify the following options in the Roll Forward DB dialog:
This retracts all changes made to the database after this time, not just those made to the table with the error.
To ensure that the error is not reintroduced when you perform a roll forward in the future, take a new checkpoint to reset the journals.
|
|
|
The roll forward end time option (specified in the Before edit control) permits the recovery of a subset of data in the journal file. The option is useful when problems have been encountered in a full roll forward database operation or when, for example, a critical piece of data has been inadvertently deleted.
There is one important consideration when using this option. As this form of recovery does not restore the database to the state reflected by the full set of journals, it is critical that a checkpoint of the database be performed after the recovery completes. If not, another roll forward performed later can leave the database in an inconsistent state.
The only recommended course of action is to roll forward a database with the Before value specified:
Note: The Before and End options operate on End Transaction timestamps, not on the time that a user can associate with an update. The audit database End and Before options (in the Audit Database dialog) also operate on End Transaction timestamps, and can be used to check anticipated roll forward results.
|
|
|
If the most recent checkpoint has been damaged or is unreadable, it is possible to recover from an older checkpoint. You can use either a specific checkpoint number or the most recent usable checkpoint.
To recover the database from a particular checkpoint and apply all journals after that time, enable the From Specified Checkpoint check box and enter the checkpoint number in the corresponding spin box.
The checkpoint sequence number must be a valid checkpoint number. You can verify this number in the Infodb dialog, invoked by the Database Infodb menu command.
If the most recent checkpoint is unfinished and you want to recover using the most recent usable finished checkpoint, enable the From Specified Checkpoint check box and do not enter a corresponding checkpoint number.
The From Specified Checkpoint option can also be used with the After and Before edit controls if you want to restore a database to its state at some previous moment in time.
Caution! You must exercise extreme caution with the After and Before options. Because these commands roll the database forward to a point in time other than that fully represented by the journals, transactions that were performed after the Before time or before the After time are lost. Partially completed transactions can be backed out by the roll forward process. Furthermore, a checkpoint must always be performed after completion of such a roll forward, thereby ensuring that obsolete journal data is not inadvertently reused in a subsequent recovery (or by an audit database operation to produce inaccurate auditing results).
Note: The audit database After and Before options behave as do the equivalent roll forward flags, and can be used to predict roll forward results.
For a full explanation of the options associated with roll forward operation, see the Roll Forward DB dialog topic in the VDBA online help. It can be accessed through the Recovering a Database From Checkpoints topic in the Procedures section.
|
|
|
In the unlikely event of a loss of the transaction log file (or, if dual logging is enabled, loss of both file copies), the following recovery procedure can be used to restore as much database information as is possible. Follow these steps:
If you are using online checkpoints and journaled databases, bring the installation back up with the newly initialized log file. All databases open at the time of the failure can be marked inconsistent by the recovery process. Each must be recovered in turn by the roll forward database operation. The Enable Journaling option with roll forward is specified for journaled databases; this option is not specified for those databases that are not journaled.
Note: A roll forward operation restores databases to a consistent state even if incomplete transaction histories have been copied to the journal files.