Performing a redirected restore operation

A database restore operation uses a database backup image to recreate a database.

Use a redirected restore operation in any of the following situations:

If you want to restore a backup image to a target machine that is different from the source machine
If you want to restore your table space containers into a different physical location
If your restore operation failed because one or more containers are inaccessible
If you want to redefine the paths of a defined storage group

Restrictions:: You cannot use a redirected restore to move data from one operating system to another.; You cannot create or drop a storage group during the restore process.; You cannot modify storage group paths during a table space restore process even if you are restoring all table spaces that are associated with the storage group.

The process for performing a redirected restore by using an incremental backup image is similar to the process of performing a redirected restore by using a non-incremental backup image. Use one of the following approaches:

Issue the RESTORE DATABASE command with the REDIRECT parameter, and specify the backup image to use for the incremental restore of the database.
Generate a redirected restore script from a backup image, and then modify the script as required.

Using the RESTORE DATABASE command approach is a two-step database restore process with an intervening step for defining a table space container or storage group path. To perform a redirected restore:

Issue the RESTORE DATABASE command with the REDIRECT parameter.
Take one of the following steps:
- Define table space containers by issuing the SET TABLESPACE CONTAINERS command.
- Define storage group paths for the database to be restored by issuing the SET STOGROUP PATHS command.
Issue the RESTORE DATABASE command again, this time specifying the CONTINUE parameter.

After you issue the RESTORE CONTINUE command, the new path takes effect as the table space container path for all associated table spaces. If you issue a LIST TABLESPACE CONTAINERS command or a GET SNAPSHOT FOR TABLESPACES command after the SET STOGROUP PATHS command and before the RESTORE CONTINUE command, the output for the table space container paths does not reflect the new paths that you specified by using the SET STOGROUP PATHS command.

During a redirected restore operation, directory and file containers are automatically created if they do not exist. The database manager does not automatically create device containers.

Db2® database products provide SQL statements for adding, changing, or removing table space containers non-automatic-storage DMS table spaces, and storage group paths of automatic storage table spaces. A redirected restore is the only way to modify a non-automatic-storage SMS table space container configuration.

You can redefine table space containers or modify storage group paths by issuing the RESTORE DATABASE command with the REDIRECT parameter.

Table space container redirection provides considerable flexibility for managing table space containers. You can alter the storage group configuration of a database before restoring any data pages from the backup image, similar to the way that you can redirect table space container paths. If you renamed a storage group since you produced the backup image, the storage group name that is specified by the SET STOGROUP PATHS command refers to the storage group name from the backup image, not the more recent name.

Performing a redirected restore operation in a partitioned database environment

In a partitioned database environment, during a redirected database restore, you can redirect the storage group paths to new storage group paths only from the catalog database partition. For all other database partitions you must have their storage group paths synchronized with those of the catalog partition.

Modifying any storage group paths on the catalog partition places all non-catalog partitions into a RESTORE_PENDING state. If you redirect storage group paths, you must restore the catalog partition before any other database partition. After you restore the catalog database partition, you can restore the non-catalog database partitions in parallel, without any storage group path redirection. The non-catalog database partitions automatically acquire the new storage group paths that you specified for the catalog database partition. New storage group paths are also automatically acquired when the storage group paths are implicitly changed during a database restore when you are restoring a different database (one with a different name, instance, or seed).

If you modified the storage group paths since taking the last backup, you can still use that backup image (with different storage group paths) for a restore on any database partition. This restore is not considered a redirected restore. Restoring from that backup image temporarily causes the database partition to use the storage group paths that you defined at the time that you created the backup. Perform a rollforward recovery to reapply the storage group path modifications and resynchronize all of the database partitions.

Examples

Example 1

You can perform a table space container redirected restore on database SAMPLE by using the SET TABLESPACE CONTAINERS command to define table space containers:

   db2 restore db sample redirect without prompting
   SQL1277W A redirected restore operation is being performed. 
   During a table space restore, only table spaces being restored can 
   have their paths reconfigured. During a database restore, storage 
   group storage paths and DMS table space containers can be reconfigured. 

   DB20000I The RESTORE DATABASE command completed successfully.

   db2 set tablespace containers for 2 using (path 'userspace1.0', path    
   'userspace1.1')
   DB20000I The SET TABLESPACE CONTAINERS command completed successfully.

   db2 restore db sample continue
   DB20000I The RESTORE DATABASE command completed successfully.

Example 2

You can redefine the paths of the defined storage group by using the SET STOGROUP PATHS command:

   RESTORE DB SAMPLE REDIRECT

   SET STOGROUP PATHS FOR sg_hot ON '/ssd/fs1', '/ssd/fs2'
   SET STOGROUP PATHS FOR sg_cold ON '/hdd/path1', '/hdd/path2'

   RESTORE DB SAMPLE CONTINUE

Example 3

Following is a typical non-incremental redirected restore scenario for a database whose alias is MYDB:

Issue a RESTORE DATABASE command with the REDIRECT option.
```
   db2 restore db mydb replace existing redirect
```
Issue a SET TABLESPACE CONTAINERS command for each table space whose containers you want to redefine. For example, in a Windows environment:
```
   db2 set tablespace containers for 5 using
          (file 'f:\ts3con1'20000, file 'f:\ts3con2'20000)                
```
To verify that the containers of the restored database are the ones specified in this step, issue the LIST TABLESPACE CONTAINERS command for every table space whose container locations are being redefined.
After successful completion of steps 1 and 2, issue:
```
   db2 restore db mydb continue
```
This is the final step of the redirected restore operation.
If step 3 fails, or if the restore operation has been aborted, the redirected restore can be restarted, beginning at step 1.

Note:

After successful completion of step 1, and before completing step 3, the restore operation can be aborted by issuing:
```
   db2 restore db mydb abort
```
If step 3 fails, or if the restore operation has been aborted, the redirected restore can be restarted, beginning at step 1.

Example 4

Following is a typical manual incremental redirected restore scenario for a database whose alias is MYDB and has the following backup images:

   backup db mydb
   Backup successful. The timestamp for this backup image is : <ts1>

   backup db mydb incremental
   Backup successful. The timestamp for this backup image is : <ts2>

Issue a RESTORE DATABASE command with the INCREMENTAL and REDIRECT options.

   db2 restore db mydb incremental taken at <ts2> replace existing redirect

Issue a SET TABLESPACE CONTAINERS command for each table space whose containers must be redefined. For example, in a Windows environment:
```
   db2 set tablespace containers for 5 using
          (file 'f:\ts3con1'20000, file 'f:\ts3con2'20000)
```
To verify that the containers of the restored database are the ones specified in this step, issue the LIST TABLESPACE CONTAINERS command.
After successful completion of steps 1 and 2, issue:
```
   db2 restore db mydb continue
```
The remaining incremental restore commands can now be issued as follows:
```
   db2 restore db mydb incremental taken at <ts1>
   db2 restore db mydb incremental taken at <ts2>
```
This is the final step of the redirected restore operation.

Note:

After successful completion of step 1, and before completing step 3, the restore operation can be aborted by issuing:
```
   db2 restore db mydb abort
```
After successful completion of step 3, and before issuing all the required commands in step 4, the restore operation can be aborted by issuing:
```
   db2 restore db mydb incremental abort
```
If step 3 fails, or if the restore operation has been aborted, the redirected restore can be restarted, beginning at step 1.
If either restore command fails in step 4, the failing command can be reissued to continue the restore process.

Example 5

Following is a typical automatic incremental redirected restore scenario for the same database:

Issue a RESTORE DATABASE command with the INCREMENTAL AUTOMATIC and REDIRECT options.

   db2 restore db mydb incremental automatic taken at <ts2>
          replace existing redirect

Issue a SET TABLESPACE CONTAINERS command for each table space whose containers must be redefined. For example, in a Windows environment:
```
   db2 set tablespace containers for 5 using
          (file 'f:\ts3con1'20000, file 'f:\ts3con2'20000)
```
To verify that the containers of the restored database are the ones specified in this step, issue the LIST TABLESPACE CONTAINERS command.
After successful completion of steps 1 and 2, issue:
```
   db2 restore db mydb continue
```
This is the final step of the redirected restore operation.

Note:

After successful completion of step 1, and before completing step 3, the restore operation can be aborted by issuing:
```
   db2 restore db mydb abort
```
If step 3 fails, or if the restore operation has been aborted, the redirected restore can be restarted, beginning at step 1 after issuing:
```
   db2 restore db mydb incremental abort
```