Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see BMC AMI Recover for Db2 13.1.

Migrating data

This section provides examples for data migration using the BMC AMI Recover INCOPY and OBIDXLAT keywords (no Recovery Management for Db2 solution password required).

Overview of migrating data

BMC AMI Recover supports data migration from one Db2 table space to another. Table spaces may reside on the same Db2 subsystem or on different Db2 subsystems or data sharing groups.

Important

If you own a Recovery solution, the migration process is simplified with the Copy Migration feature. For information on how to use the IMPORT (IMPORT-command) and MIGRATE (MIGRATE-command) commands, see theRecovery Management for Db2 documentation. These commands eliminate the need to code the INCOPY and OBIDXLAT keywords.

Also, note that Online Consistent Copy can create a consistent copy without a quiesce by using Instant Snapshots. For examples, see theRecovery Management for Db2 documentation.

Finally, note that there are special considerations for migrating versioned tables. For more information, see Handling-Db2-versioning-information.

The following figure shows how you can use BMC AMI Recover to migrate data from a production table space to a table space on a different subsystem designated for high-level query functions.

GUID-B6D7D562-74E3-42D9-929D-6A4E7A8812E6-low.png

In this example, it is assumed that both Db2 subsystems run on systems that share a common DASD pool.

You use BMC AMI Recover to build a table space and index set for the receiving Db2 system by using copies, change accumulation files, and logs made for recovery purposes on the sending Db2 system. To perform the migration, you use the INDEPENDENT OUTSPACE option and the OBIDXLAT option.

You can migrate the indexes using copies and logs in the same manner as the table space. Alternatively, you can rebuild the indexes by specifying the newly migrated table space with the INDEPENDENT INTABLESPACE option. In either case, the structure of the indexes cannot be different in this scenario. (Some indexes may be eliminated, however.)

The following figure demonstrates how you can use BMC AMI Recover to migrate data to remote sites. In this example, the recovery resources on the sending subsystem are used to build a reference migration image. A reference migration image is identical to a SHRLEVEL REFERENCE image copy.

GUID-3930669B-719E-4C71-BEA6-193B24883E07-low.png

One copy of this image copy may be registered at the sending site for use in normal Db2 recovery operations. Another copy could be sent off site to build a query version of the production table space at a remote location.

At the receiving site, you can use the INCOPY option of BMC AMI Recover to restore the reference migration image to the query version of the object.

Indexes can also be migrated using the reference migration image. However, if you rebuild the indexes instead, the index structure may be different on the query system to optimize query access (for example, using QMF).

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*