Using restore

The database can be local or remote.

• You can only use the restore utility if the database has been previously backed up using the DB2® backup utility.
• If users other than the instance owner (on UNIX), or members of the DB2ADMNS or Administrators group (on Windows) attempt to restore a backup image, an error is returned. If other users need access to the backup image, the file permissions need to be changed after the backup is generated.
• A database restore operation cannot be started while the rollforward process is running.
• If you do not specify the TRANSPORT option, then you can restore a table space into an existing database only if the table space currently exists, and if it is the same table space; "same" means that the table space was not dropped and then recreated between the backup and the restore operation. The database on disk and in the backup image must be the same.
• You cannot issue a table space-level restore of a table space-level backup to a new database.
• You cannot perform an online table space-level restore operation involving the system catalog tables.
• You cannot restore a backup taken in a single database partition environment into an existing partitioned database environment. Instead you must restore the backup to a single database partition environment and then add database partitions as required.
• When restoring a backup image with one code page into a system with a different codepage, the system code page will be overwritten by the code page of the backup image.
• You cannot use the RESTORE DATABASE command to convert nonautomatic storage enabled table spaces to automatic storage enabled table space.
• The following restrictions apply when the TRANSPORT option is specified:
  • If the backup image can be restored by a restore operation, and is supported for upgrades, then it can be transported.
  • If an online backup is used, then both source and target data servers must be running the same DB2 version.
  • The RESTORE DATABASE command must be issued against the target database. If the remote client is of the same platform as the server, then schema transport can be executed locally on the server or through remote instance attachment. If a target database is a remote database cataloged in the instance where transport runs locally, then schema transport against that remote target database is not supported.
  • You can only transport tables spaces and schemas into an existing database. The transport operation will not create a new database. To restore a database into a new database, you can use the RESTORE DATABASE command without specifying the TRANSPORT option.
  • If the schemas in the source database are protected by any DB2 security settings or authorizations, then the transported schemas in the target database will retain these same settings or authorizations.
  • Transport is not supported in partitioned database environments.
  • If any of the tables within the schema contains an XML column, the transport fails.
  • The TRANSPORT option is incompatible with the REBUILD option.
  • The TRANSPORT option is not supported for restore from a snapshot backup image.
  • The target database must be enabled for database recovery.
  • The staging database is created for transport. It cannot be used for other operations.
  • The database configuration parameters on the staging table and the target table need to be the same, or the transport operation fails with an incompatibility error.
  • The auto_reval configuration parameter must be set to deferred_force on the target database to transport objects listed as invalid. Otherwise, the transport will fail.
  • If an online backup image is used, and the active logs are not included, then the transport operation fails.
  • If an online backup is used, then the backup image must have been created with the INCLUDE LOGS option
  • If the backup image is from a previous release, it must be a full offline database level backup image.
  • If an error occurs on either the staging or target database, the entire restore operation must be reissued. All failures that occur are logged in the db2diag log file on the target server and should be reviewed before reissuing the RESTORE command.
  • If the transport client fails, then the staging database might not be properly cleaned up. In this case, you need to drop the staging database. Prior to re-issuing the RESTORE command, drop all staging databases to prevent containers of staging database from blocking subsequent transport.
  • Concurrent transport running against the same target database is not supported.
  • Generating a redirected restore script is not supported with table space transport.
  • You cannot use the Restore wizard to execute schema transport.