Topics | How To | Full System Restore | Related Topics
Restore Considerations for this Agent
Restore DB2 Databases Created in a User-defined Directory
Restore DB2 Databases with Specific Parameters Containing a Non-default Value
The following page describes the agent-specific restore options. Additional restore options are accessible from the Related Topics menu.
The DB2 iDataAgent supports the following types of restores:
Recovery involves two processes: restoring the physical files and then recovering the database. The user can either select backup images to be restored or have the system select the backup image. After the necessary files are restored, the database is recovered (and, in some cases, rolled forward) by applying the appropriate log files.
Additionally, the DB2 iDataAgent supports specific procedures for doing the following:
Depending on your restore options, restores can be performed in-place, out-of-place or cross-platform. (See Restore Destinations below for comprehensive information.) Also, DB2 restore jobs can be run from a third-party command line, and they cannot be suspended unless they are in a pending state.
For the DB2 iDataAgent, restore operations can be performed from the client and backup set levels in the CommCell Browser.
When there is a problem with DB2 database or the client system (operating system, hardware, hard drives, etc.), full system restores may be required. See Restore Data - DB2 iDataAgent - Full System Restore for more information.
If the database is upgraded, the next backup that is run detects the new version. The version is refreshed and displayed in the instance Properties dialog box and for the SQL Server iDataAgent, it is displayed during a browse operation. For more information, see Browse Databases.
The system attempts to restore the DB2 backup images within a backup cycle in a specific order, as follows:
For example, assume that Backup Cycle A includes the following backup images (F represents a full backup image, D represents a delta backup image, and I represents an incremental backup image).
Using the rules in the previous bullet list, the backup images in Backup Cycle A would be restored in the following order.
Note that Delta Backup Image 5 (i.e., D5) is the last backup image in Backup Cycle A. Therefore, it is restored first and then last when the backup images in the cycle are restored. Note also that Full Backup Image 1 (i.e., F1) is restored second, and that the remaining backup images are restored in the appropriate order.
The information in this section is important if you try to restore a full backup image along with one or more associated incremental backup images and/or delta backup images but one of these backup images fails to restore. In such a case, you must follow the appropriate steps to implement a successful restore. For more information, see the appropriate how-to topic.
The following list discusses the DB2-specific restore options that are provided by the agent. The options that are also available to other agents are not discussed here.
The following options are provided from the Restore Options dialog box in the CommCell Browser.
The Source & Destination tab allows you to select the data to restore and the destination(s) for the restore. It also provides an option to administer table space containers. You should use this option if your system has lost containers (because of a crash, for example) or if one or more current containers are full.
The Restore Arguments tab allows you to administer the type of restore, the backup images available for restore, and the DB2 Report File. For each full backup image that you select to restore, be sure to select all associated incremental or delta backup images as well. Whenever this tab is enabled, the Recover Database tab is disabled.
The Recover Database tab allows the DB2 iDataAgent to select the backup image to restore and therefore obviates the need for the user to select backup images for restore. The backup image selected is always for the entire database; as such, partial database restores are not supported by this option. Also, out-of-place restores are not supported by this option. Whenever this option is enabled, the Restore Arguments tab is disabled.
| If the database to be recovered is dropped or deleted, you cannot use this option. In such a case, click Advanced and use the Roll-Forward option. |
The following options are provided from the Advanced Restore Options dialog box in the CommCell Browser.
| These options will be disabled if you use the Recover Database tab. |
The Log Files tab allows you to administer log file restores. Whenever log files are restored without rolling forward the database, the files are restored to the DB2 Retrieve Path that was specified during the installation of the DB2 iDataAgent.
The Roll-Forward tab allows you to recover the DB2 database by reapplying the log files containing transactions that are not part of any database backup image. The roll-forward capability is invoked after a database or table space image is restored. Before the database can be "rolled forward," you must perform log archiving by doing one or both of the following: having the logretain database configuration parameter set to "RECOVERY"; and/or enabling the userexit database configuration parameter.
| You do not need (and are not able) to use the Roll-Forward tab if you use the Recover Database tab to have the DB2 iDataAgent select the backup image for restore. You can use the Roll-Forward tab if you use the Restore Arguments tab to select the backup images for restore. |
The Redirect tab allows you to rename one or more table spaces or table space containers upon restore. Renaming these items as they are restored allows them to be restored without overwriting existing table spaces or table space containers.
We cannot use redirect restore process for automatic databases. If the database is automatic the Storage Paths tab will appear instead of Redirect tab in the Advanced Restore Options dialog box. To restore auto database’s table space to another storage path, you can specify new storage path to which automatic databases should be restored.
Whenever log files are restored with the roll-forward option activated, DB2 searches for the following target restore paths per the following order: DB2's own directory path for log file restores; the DB2 Retrieve Path that was specified during the installation of the DB2 iDataAgent; the DB2 Archive Path that was specified during the installation of the DB2 iDataAgent; and the path identified (if any) in the Overflow Directory field within the Roll-Forward tab.
If DB2 is unable to find any of these paths, the appropriate error is reported in a file within the DB2 Audit Error Path that was specified during installation of the DB2 iDataAgent.
You can troubleshoot restores by checking the CLDb2Agent restore log located <software installation path>\Log Files. Also, you can check details on the restore by issuing the db2ckrst DB2 command and then reviewing the generated output. The output for this command lists all of the backup images involved in the restore. The command syntax is as follows:
db2ckrst [-d <database name>] [-t <timestamp string>]
where:
<database name> is the name of the
database
<timestamp string> is a numerical
value representing the backup image involved
in the restore.
| Timestamps are displayed in the Restore Options (Restore Arguments) dialog box in the CommCell Browser. |
For example:
db2ckrst -d db_one -t 20030224125749
might generate the following output:
Suggested restore order of images using timestamp
20030224125749
for database db_one
============================================================
restore db db_one incremental taken at 20030224125749
restore db db_one incremental taken at 20030224124314
restore db db_one incremental taken at 20030224125211
restore db db_one incremental taken at 20030224125749
=============================================================
In this example, note that the timestamp for the database image included in the command appears twice in the output — in the first line and in the last line. This indicates that this (delta or incremental) backup image was the last backup image in the backup cycle and therefore was restored first and then last among all of the backup images in the cycle.
If a restore job fails, and if the job contains just one backup image, you can simply rerun the restore job as you had done previously. However, if the failed restored job contains multiple backup images, you must rerun the restore job by following the appropriate procedure. One procedure is based on a full backup image restore failure, while the other procedure is based on either a delta backup image restore failure or an incremental backup image restore failure.
|
You can view backup image restore failures
by checking the system logs. For information on system logs, see
Log Files. Also, you can view details on all the backup images included in a restore by
checking the output of the db2ckrst
command. See Restore Order of DB2 Backup Images within a Cycle for a discussion of restoring multiple DB2 backup images within a backup cycle. |
If you defined your own directory for the database instead of using the DB2 default location when you created the database, you cannot restore this database to either a new database or another instance in the conventional manner.
If the DBHEAP, UTIL_HEAP, and/or APP_CTL_HEAP_SZ configuration parameters for the (source) database that you want to restore contain a value other than the default value, you cannot restore this database to either a new database or another instance in the conventional manner.
By default, the DB2 iDataAgent restores data to the client computer from which it originated; this is referred to as an in-place restore. You can also restore the data to another Client computer in the CommCell. Keep in mind the following considerations when performing such restores:
The following section enumerates the types of restore destinations that are supported by the DB2 iDataAgent. See Restore/Recover/Retrieve Destinations - Support for a list of Agents supporting each restore destination type.
If the DB2 Automatic Storage feature was used to create the DB2 database(s), in-place restores will work. Out-of-place restores and cross-platform restores discussed below will not work. Therefore, to run such restores successfully, be sure to create the DB2 database(s) with the Automatic Storage feature disabled before you run the restores.
However, Out of place Restores for Automatic Storage feature enabled DB2 Databases are supported through DB2 Command Line. See sample script for performing out-of-place restore using DB2 Command Line.
Keep in mind that out-of-place restore operations are also subject to the conditions described in Cross-Platform Restores.
| Out-of-place restores are not supported by the Recover Database option. |
You should restore DB2 database data to a different host (or out of place) if the original host is damaged. This is sometimes called a cross-machine restore. Whenever you perform such a restore, ensure that the destination machine has sufficient disk space to accommodate the restored database.