Troubleshooting: transporting schemas
If an error occurs on either the staging or target database, you must redo the entire restore operation. All failures that occur are logged in the db2diag log file on the target server. Review the db2diag log before reissuing the RESTORE command.
Dealing with errors
Errors occurring during restore are handled in various ways depending on the type of object being copied and the phase of transport. There might be circumstances, such as a power failure, in which not everything is cleaned up.
- Staging database creation
- Physical table space container restoration
- Rollforward processing
- Schema validation
- Transfer of ownership of the table space containers
- Schema re-creation in target database
- Dropping the staging database (if the STAGE IN parameter is not specified)
If any errors are logged at the end of the schema re-creation phase, about transporting physical objects, then the restore operation fails and an error is returned. All object creation on the target database is rolled back, and all internally created tables are cleaned up on the staging database. The rollback occurs at the end of the re-create phase, to allow all possible errors to be recorded into the db2diag log file. You can investigate all errors returned before reissuing the command.
The staging database is dropped automatically after success or failure. However, it is not dropped in the event of failure if the STAGE IN parameter is specified. The staging database must be dropped before the staging database name can be reused.