Topics | How To | Full System Restore | Related Topics
Restore Considerations for this Agent
Restoring the Database to a New Client (Out-of-Place)
Restore DB2 Databases Created in a User-defined Directory
Restore DB2 Databases with Specific Parameters Containing a Non-default Value
Third Party Command Line Restores
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 General 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.
| 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. |
Use the following steps to restore all of the log files.
|
 |
Use the following steps to restore log files to a point-in-time.
|
 |
Use the following steps to restore log files to a point-in-time.
|
 |
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.
Use the following steps to redirect all the table spaces.
|
 |
Use the following steps to redirect specific table spaces.
|
 |
An automatic storage database is one in which container and space management characteristics are completely determined by the DB2 database manager. We cannot use redirect restore process for automatic storage databases. For automatic storage databases the Storage Paths tab will appear instead of Redirect tab in the Advanced Restore Options dialog box.
Use the following steps to restore table space of an automatic storage database to another path.
|
 |
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.
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.
Use the following steps to reapply all of the logs to the database after a restore.
|
 |
Use the following steps to reapply logs till a point-in-time to the database after a restore.
|
 |
Use the following steps to keep the database in a pending state till the logs are reapplied.
|
 |
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. |
You can restore an entire DB2 database after you bring down the affected database offline. However, the database will be deactivated and all the db2 non administrative users will be disconnected automatically during a restore operation. The system will automatically activate the database after the restore operation.
Follow the steps given below to restore an entire db2 database:
|
 |
When restoring databases to a new client, ensure the following:
|
 |
|
 |
If the original host is damaged, you can restore the DB2 database to a different instance on the same host or to a different host. Whenever you perform a cross-machine restore, ensure that the destination computer has sufficient disk space to accommodate the restored database.
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.
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 can perform restores of one of more databases from the command line interface.
Command line restores enable you to perform restore operations on multiple clients at the same time. It also allows you to reuse the command line scripts for additional restores.
When performing command line restores, note that backups taken from the CommCell Console can be restored using Command Line and vice versa. However, backups taken from a previous version of the CommCell Console can be restored only from the Command Line.
In order to run the restores from command line, you need an input xml file which contains the parameters for configuring the restore options. This input xml file can be obtained using one of the following ways:
To run command line operations you must first login to the CommServe as follows:
qlogin -cs <commserve name> -u <user name>
qlogin -cs server1 -u user1
qoperation execute -af recover_template.xml -clientName <DB2CleintName> -instanceName <DB2InstanceName> -backupsetName <DB2BackupSetName>
Example
qoperation execute -af qoperation_db2_recover.xml -clientName dbserveaix2 -instanceName db2inst5 -backupsetName TESTDB
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
Use the following steps to restore a DB2 database. You must deactivate the database before performing a DB2 database restore.
db2 restore db <database name> incremental automatic load '<software install path>/Base/libDb2Sbt.so' taken at <backup image date> without prompting
db2 restore db <database name> incremental automatic load '<software install path>/Base64/libDb2Sbt.so' taken at <backup image date> without prompting
db2 restore db <database name> incremental automatic load '<software install path>/Base/Db2Sbt.dll' taken at <backup image date> without prompting
where <software install path> is the install path for the agent software (e.g., level1/install); and <backup image date> is the date of the backup image in the following format: "YYYYMMDDHHMMSS" (e.g., 20070612120426).
db2 rollforward db <database name> to end of logs and complete
| 1. | At the Command Prompt, type the restore command. | db2 restore db <database name> load '<software install path>/Base/libDb2Sbt.so' taken at <backup image date> without prompting |
| 1. | At the Command Prompt, type the restore command. | db2 restore db <database name> incremental automatic load '<software install path>/Base/libDb2Sbt.so' taken at <backup image date> without prompting |
| 1. | At the Command Prompt, type the restore command. | db2 restore db <database name> incremental automatic load '<software install path>/Base/libDb2Sbt.so' taken at <backup image date> without prompting |
When you perform third party command line restores from multiple stream
backups, the restore operation will generate separate job ID for each stream.
You can perform a third party command line restore from a multistream backup
image using the following steps. Note that the number of streams specified for
the restore should be same as the number of streams used by the backup image.
| 1.. | At the Command Prompt, type the appropriate restore command for the specific platform. |
On Unix client: db2 restore db <db_name> load '<software install path>/Base(or Base64)/libDb2Sbt.so' open <n> sessions taken at <backup_image> On Windows client: db2 "restore db <db_name> load '<software install path>\Base\Db2Sbt.dll' open <n> sessions taken at <backup_image>" |
| 2. | Roll forward the DB2 database | db2 rollforward db <database name> to end of logs and complete |
Use the following steps to perform a cross-database restore involving the same DB2 instance, assume, for example, that the name of the source database is pubs and that the name of the target database is emp.
| 1. | At the Command Prompt, type the restore command. | db2 restore db pubs load <source software install path>/Base/libDb2Sbt.so taken at 20080627113811 on <destination software install path> into emp |
| 2. | Set the CvSrcDbName option for the LOGARCHOPT1 parameter to the source database name. | db2 update db cfg for emp using LOGARCHOPT1 "'CvSrcDbName=pubs,CvClientName=<client name>,CvInstanceName=<CommServe instance name>"' |
| 3. | Roll forward the DB2 database | db2 rollforward db emp to end of logs and stop |
Use the following steps to perform a cross-database restore involving different DB2 instances on the same client, assume, for example, that the name of the (source and destination) client is supernova, the name of the source DB2 instance is db2inst3, the name of the source database is pubs, the name of the destination DB2 instance is db2inst4, and the name of the destination database is emp01. Also, assume that the CommServe instance name (in a multi-instance environment) is Instance001.
| 1. | Set the CvSrcDB2InstanceName option to the source database name in the VENDOROPT parameter (in this example, db2inst3). |
db2 update db cfg for emp01 using VENDOROPT "'CvSrcDB2InstanceName=db2inst3,CvClientName=supernova, CvInstanceName=Instance001"' |
| 2.. | At the Command Prompt, type the restore command. | db2 restore db pubs load <source software install path>/Base/libDb2Sbt.so taken at 20080627113811 on <destination software install path> into emp01 |
| 3. | Set the CvSrcDbName option to the source database name and the CvSrcDB2InstanceName option to the source DB2 instance name in the LOGARCHOPT1 parameter. |
db2 update db cfg for emp01 using LOGARCHOPT1
"'CvSrcDbName=pubs,CvSrcDB2InstanceName=db2inst3, CvClientName=supernova, CvInstanceName=Instance001"' |
| 4. | Roll forward the DB2 database | db2 rollforward db emp to end of logs and stop |
For a cross-database restore involving different DB2 instances on different clients, assume, for example, that the name of the source client is supernova, the name of the source DB2 instance is db2inst3, the name of the source database is pubs, the name of the destination client is neutronstar, the name of the destination instance is db2inst4, and the name of the destination database is emp. Also, assume that the CommServe instance name (in a multi-instance environment) is Instance001.
| 1. | Set the CvSrcClientName option to the source client name and the CvSrcDB2InstanceName option to the source database name in the VENDOROPT parameter (in this example, db2inst3). |
db2 update db cfg for emp01 using VENDOROPT "'CvSrcClientName=supernova,CvSrcDB2InstanceName=db2inst3, CvClientName=neutronstar,CvInstanceName=Instance001"' |
| 2. | At the Command Prompt, type the restore command. | db2 restore db pubs load <source software install path>/Base/libDb2Sbt.so taken at 20080627113831 on <destination software install path> into emp |
| 3. | Set the CvSrcDbName option to the source database name, the CvSrcClientName option to the source client name, and the CvSrcDB2InstanceName option to the source instance name in the LOGARCHOPT1 parameter. |
db2 update db cfg for emp using LOGARCHOPT1 "'CvSrcDbName=pubs,CvSrcClientName=supernova, CvSrcDB2InstanceName=db2inst3,CvClientName=neutronstar, CvInstanceName=Instance001"' |
| 4. | Roll forward the DB2 database | db2 rollforward db emp to end of logs and stop |