Once a database backup is made, there are several ways to restore the database. This section briefly describes the following:
For complete details, see the Administration Guide.
DB2 will automatically recover from system crashes, even with the default of circular logging. All committed units of work that are not written to disk will be redone when the system comes back up and the first application connects to a database or when a database is restarted (from the database you want to restart in the object tree, select Restart from its pop-up menu). Crash recovery is performed during restart processing.
The Restore Database SmartGuide will help you restore a database to the point in time of the last database backup or the last complete transaction. The recovery plan you created for this database determines what is possible.
To restore a database:
Confirm that the name of the database to restore is correct. If you want, you can specify the name of a different database.
To do a basic restore of the specified database (that is, using the most recent backup and rolling forward to the end of the logs), click on the Done push button.
If you wish to modify the restoration parameters, click on the Next push button to continue through the remaining steps.
You need to roll forward (reapply) the changes to your database since the last time you backed it up. Those changes are stored in a set of log files. If you cannot roll forward all the changes since the last backup, you can roll forward to a specific point in time. If you choose to roll forward to a point in time, you can choose to do more later, or stop and make the database available for use.
Occasionally, you may need to undo something that happened to your database: for example, if an errant application program has damaged your data, you would want to put the database back to the point just before that application program was run against it. To do this, use the Restore Database SmartGuide to perform a full database restore, but in the last step, specify a date and time to which you wish to roll forward your database using the logs.
In many cases, a disk failure does not involve a loss of data. If it does, you must perform a restore.
Unless the failing disk is part of a disk array, your database will be down and unavailable to users. First, you need to replace the drive, then follow the steps in "How Do I Perform a Full Database Restore?" to perform a full database restore, and roll forward the database using the logs.
As an alternative to first waiting for hardware repairs, you could perform a redirected restore, to restore the database to some other undamaged disk. You can perform a redirected restore from the Restore Database notebook (from the database you want to restore, select Restore -> Database from the pop-up menu). See the Administration Guide for more information about redirected restores. As indicated earlier, you generally should not keep the logs on the same physical disk as the database, since in that case you would be unable to roll forward to your most recent transaction.
If the failed disk was part of a disk array, the database will still be running, and you can simply replace the disk in the array at a later time. A disk array consists of a collection of disk drives that appear as a single large disk drive to an application. See the Administration Guide for more information.