Errors occurring during a db2move COPY operation can be handled in various ways depending on the type of object being copied, or the phase during which the COPY operation failed (that is, either the recreation of objects phase, or the loading of data phase).
The db2move utility reports errors and messages to the user using message and error files. Copy schema operations use the COPYSCHEMA_timestamp.MSG message file, and the COPYSCHEMA_timestamp.err error file. These files are created in the current working directory. The current time is appended to the file name to ensure uniqueness of the files. It is up to the user to delete these message and error files when they are no longer required.
The type of object being copied can be categorized as one of two types: physical objects and business objects.
A physical object refers to an object that physically resides in a container, such as tables, indexes and user-defined structured types. A business object refers to cataloged objects that do not reside in containers, such as views, user-defined structured types (UDTs), and aliases.
Errors occurring during the recreation of a physical object cause the utility to roll back, whereas, errors during the recreation of a logical object do not.
To restart the copy schema operation:
db2move sourcedb COPY -tf LOADTABLE.err -co TARGET_DB mytarget_db
-mode load_only
db2move sourcedb COPY -tn "FOO"."TABLE1","FOO 1"."TAB 444",
-co TARGET_DB mytarget_db -mode load_only
Sample output for the COPYSCHEMA_timestamp.err error file:
1. schema: FOO.T1
Type: TABLE
Error Msg: SQL0104N An unexpected token 'FOO.T1'...
Timestamp: 2005-05-18-14.08.35.65
DDL: create view FOO.v1
2. schema: FOO.T3
Type: TABLE
Error Msg: SQL0204N FOO.V1 is an undefined name.
Timestamp: 2005-05-18-14.08.35.68
DDL: create table FOO.T3
If any errors creating physical objects are logged at the end of the recreation phase and before attempting the load phase, the db2move utility 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 source database. In order to gather all possible errors into the error file, the rollback occurs at the end of the recreation phase after attempting to re-create each object, rather than after the first failure. This allows you the opportunity to fix any problems before restarting the db2move operation. If there are no failures, the error file is deleted.
"FOO"."TABLE1"
"FOO 1"."TAB 444"
If the internal operation failure occurs during the DDL recreation phase, all successfully created objects are rolled back from the target schema. All internally created tables such as the DMT table and the db2look table, are cleaned up on the source database.
If the internal operation failure occurs during the load phase, all successfully created objects remain on the target schema. All tables that experience a failure during a load operation, and all tables which are not yet loaded, are logged in the LOADTABLE.err error file. You can then issue the db2move COPY command using the LOADTABLE.err as discussed in Example 2. If the db2move utility abends (for example a system crash occurs, the utility traps, or the utility is killed), then the information regarding which tables still must be loaded is lost. In this case, you can drop the target schema using the ADMIN_DROP_SCHEMA procedure and reissue the db2move COPY command.
Regardless of what error you might encounter during an attempted copy schema operation, you always have the option of dropping the target schema using the ADMIN_DROP_SCHEMA procedure. You can then reissue the db2move COPY command.