Administration Guide

Migration Considerations

To successfully migrate a database created with a previous version of the database manager, you must consider the following:

Migration Restrictions

There are certain pre-conditions or restrictions that you should be aware of before attempting to migrate your database to Version 7:

Security and Authorization

You need SYSADM authority to migrate your database.

Storage Requirements

Space is required for both the old and the new catalogs during the migration. The amount of disk space required will vary, depending on the complexity of the database, as well as the number and size of the database objects. These objects include all tables and views. You should make available at least two times the amount of disk space that the database catalog currently occupies. If there is not enough disk space, migration fails.

If your SYSCAT table space is an SMS type of table space, you should also consider updating the database configuration parameters that are associated with the log files. You should increase the values of logfilsiz, logprimary, and logsecond to prevent the space for these log files from running out (SQL1704N with reason code 3). If this happens, increase the log space parameters, and re-issue the MIGRATE DATABASE command.

Release-to-Release Incompatibilities

Consider the impact of incompatibilities between the two versions of the product when planning to migrate a database.

To take advantage of Version 7 enhancements, you should tune your database and database manager configuration after migrating your databases. To facilitate this, you can record and compare configuration parameter values from before and after migration. (For a description of the GET DATABASE CONFIGURATION command and the GET DATABASE MANAGER CONFIGURATION command, refer to the Command Reference.)

Migrating a Database

Following are the steps you must take to migrate your database. The database manager must be started before migration can begin.

PRE-MIGRATION:
Note:The pre-migration steps must be done on a previous release (that is, on your current release before migrating to, or installing, the new release).

  1. Verify that there are no unresolved issues that pertain to Migration Restrictions.
  2. Disconnect all applications and end users from each database being migrated (use the LIST APPLICATIONS command, or the FORCE APPLICATIONS command, as necessary).
  3. Use the DB2CKMIG pre-migration utility to determine if the database can be migrated (for detailed information about using this utility, see the Quick Beginnings book for your platform). Note that on Windows NT or OS/2, you are prompted to run this tool during installation, but on UNIX based systems, this tool is invoked automatically during instance migration.
  4. Back up your database.

    Migration is not a recoverable process. If you back up your database before the Version 6 reserved schema names are changed, you will not be able to restore the database using DB2 UDB Version 7. To restore the database, you will have to use your previous version of the database manager.

    Attention! If you do not have a backup of your database, and the migration fails, you will have no way of restoring your database using DB2 UDB Version 7, or your previous version of the database manager.

    You should also be aware that any database transactions done between the time the backup was taken and the time that the upgrade to Version 7 is completed are not recoverable. That is, if at some time following the completion of the installation and migration to Version 7, the database needs to be restored (to a Version 7 level), the logs written before Version 7 installation cannot be used in roll-forward recovery.

    MIGRATION:

  5. Migrate the database using one of the following:

    On OS/2: The DB2CIDMG migration utility, which works in a Configuration/Installation/Distribution (CID) architecture environment, is only available on DB2 for OS/2. It permits remote unattended installation and configuration on LAN-based workstations. You must have NetView DM/2 on your LAN to use CID migration.

    On UNIX based systems: The Quick Beginnings book for your platform describes what to do if you do not want to migrate all databases in a given instance.

    POST-MIGRATION:

  6. Optionally, use the DB2UIDDL utility to facilitate the management of a staged migration of unique indexes on your own schedule. (DB2 Version 5 databases that were created in Version 5 do not require this tool to take advantage of deferred uniqueness checking, because all unique indexes created in Version 5 have these semantics already. However, for databases that were previously migrated to Version 5, these semantics are not automatic, unless you use the DB2UIDDL utility to change the unique indexes.) This utility generates CREATE UNIQUE INDEX statements for unique indexes on user tables, and writes them to a file. Running this file as a DB2 CLP command file results in the unique index being converted to Version 7 semantics. For detailed information about using this utility, refer to one of the Quick Beginnings books.
  7. Optionally, issue the RUNSTATS command against tables that are particularly critical to the performance of SQL queries. Old statistics are retained in the migrated database, and are not updated unless you invoke the RUNSTATS command.
  8. Optionally, use the DB2RBIND utility to revalidate all packages, or allow package revalidation to occur implicitly when a package is first used.
  9. Optionally, migrate Explain tables if you are planning to use them in Version 7. For more information, see Chapter 26, SQL Explain Facility .
  10. Tune your database and database manager configuration parameters to take advantage of Version 7 enhancements.

[ Top of Page | Previous Page | Next Page ]