migration-enabled table – the last partition in this table should be removed when creating the disabled table. Alternatively, if the original tablespace used to hold the table prior to enabling it for migration processing still exists, this may be used.

A new table must be created in this tablespace. If the original definition used to create the table prior to enabling it for migration processing exists, this should be used. Otherwise the definition should be an exact copy of that for the migration-enabled table, with the following modifications:

o The name of the table should be the name given to the view created for accessing the migration-enabled table during migration enabling processing.

o Remove the statement ‘EDITPROC OTDBP300’ from the SQL CREATE TABLE command.

o Remove the column ‘OTDBIND’ from the SQL CREATE TABLE command.

If the migration-disabled table is partitioned, modify the existing partitioning index by removing the column OTDBIND from the index definition, modifying the VALUES statement to remove the OTDBIND entries, and removing the PART entry for the last (removed) partition.

If the migration-disabled table is not partitioned, remove the partitioning (PART) statements from the index definition.

All other existing indexes should be copied without modification to index the migration-disabled table.

The contents of the migration-enabled table should be unloaded, and loaded into the new table. Remove the entry for field OTDBIND from the SYSIN file used for the re-load job. This process will create an exact copy of the original table, with the modifications described above.

All views on the existing table (other than that having the name of the migration-disabled table itself) should be re-created as originally defined.

A table will be disabled for migration processing following completion of the above activities. DB2 Manager will then no longer be required when accessing the table.

DB2 Manager User Guide

79

StorageTek Proprietary

 

Page 82
Image 82
StorageTek 312564001 manual