IBM Support

DB2 UDB Version 8 Migration Planning

Preventive Service Planning


Abstract

This document decribes the steps you should take to migrate your DB2 instances and databases from earlier versions of DB2® Universal Database™ (DB2 UDB) to DB2 Version 8.

Content

    Pre-migration checklist



    Space Considerations
    • The catalog DMS tablespace should be at least 70% free.
    • The temporary space should be large enough to hold twice the catalog space.
    • Before running db2imigr command make sure enough space available in /tmp because migration trace file is written into this directory.
    • Ensure 2GB available free disk space for DB2 Version 8 temporary target directory.
    • Ensure 900MB available free disk space for DB2 Version 8 target directory.
    • Due to the fact there is no reverse migration the back out of migration procedure involves full restore of the backup prior to migration, it is strongly recommended to have an offline backup available prior to instance migration to DB2 version 8.
    • It is desirable that DB2 migration to version 8 be scheduled after upgrading operating systems as per release notes.
    • Ensure sufficient log space to hold active transactions, due to the fact DB2 processes migration as one transaction so all tablespaces modifications will need to fit in your currently defined log space. (consider doubling the values for logfilsiz, logprimary and logsecondary).

    Other Considerations
    • Before migration of the production server to DB2 version 8, consider testing the migration procedure on a separate system to ensure that applications and third party products work properly.
    • Record the exact environment conditions for critical production operations, identify a number of typical queries, benchmark preserving the db2expln output of each to compare plans before and after migration.
    • Save a record of table spaces for each database you are planning to migrate.

    Migration Operational steps
    • Ensure that all databases are cataloged, the db2ckmig tool will only check the cataloged databases.
    • Make an offline backup copy of your DB2 version 7 databases.
    • Save database and database manager configurations along with db2set –all, db2nodes.cfg and record the tablespaces layout; capture list tablespaces show detail on each partition.
    • Make sure the instances are shutdown by running db2stop command and shut down DAS by running the db2admin stop command.
    • Ensure that you can migrate the databases to the new version by running db2ckmig command.
    • Install DB2 Version 8, see the release notes and DB2 Quick Beginning.
    • Install the latest DB2 FixPak information.
    • Change diaglevel to 4, gives an indication of how things progressed.
    • Run the db2imigr command to migrate the instance
    DB2DIR/instance/db2imigr [-u fencedID] InstName

    where
    DB2DIR
    is /usr/opt/db2_08_01 on AIX and /opt/IBM/db2/V8.1 on all other
    UNIX-based operating systems.
    • Migrate the databases using db2 migrate database command.
    • Verify database and database manager configuration.
    • Change diaglevel to 3.
    • Back up all databases.
    • Proceed with application testing.

    Migration Restrictions
    • Migration is only supported from V6 (Linux must be V6 FP2) and V7 for all platforms.
    • Migration of an EEE system that includes multiple hosts requires that database migration be performed after DB2 Version 8 is installed on all participating hosts.
    • User objects within database cannot have DB2 reserved schema names as SYSCAT, SYSTAT, and SYSFUN.
    • User defined distinct types using the names BIGINT, REAL, DATALINK, or REFERENCE must be renamed before migrating the database.
    • Consider migrating your DB2 UDB clients to Version 8 after the server is migrated to version 8.
    • Database migration cannot proceed if database is in one of the following states:
    • -Backup pending
    • -Roll-forward pending
    • -Table spaces not in normal state
    • -Transaction inconsistent
    • Restoration of down-level database is supported, but the rolling forward of down-level logs is NOT supported.

    Migration Consideration for Clients
    Client / Server Connectivity scenarios.
    Possible scenarios to consider when planning the migration:

    Scenario 1
    V8 clients with V8 servers (no restrictions)

    If we have both 32- and 64-bit DB2 Version 8 clients, they can access Version 8 64-bit servers without DB2 Connect.

    Scenario 2
    V7 32-bit clients with V7 or V8 32-bit servers (no restrictions in a single partition database; limited restrictions in a partitioned database)

    There is no Version 7 client support in a Version 8 partitioned database environment for the SET CLIENT CONNECT_NODE or ATTACH_NODE options or for a utility flow that requires an ATTACH command. If these commands are needed, V8 client must be used instead.

    Scenario 3
    V8 clients with DB2 V7 servers (many restrictions, not recommended)

    We should not consider using this migration scenario because of the restrictions.

    Scenario 4
    V7 32-bit clients with V8 64-bit servers (limited restrictions)
    This can be implemented by using either V8 DB2 Connect or DB2 Connect loopback gateway.

    Using DB2 Connect

    Version 7 32-bit client ===>Version 8 32-bit DB2 Connect Gateway===>Version 8 64-bit server
    Windows Any supported 32-bit os 64-bit AIX/Solaris/HP-UX/Linux
    Using a DB2 Connect loopback gateway

    Version 7 32-bit client===>Version 8 32-bit DB2 Connect Gateway instance + a Version 8 64-bit server instance
    Windows

    Steps to catalog a loopback node:

    On the server:
    $ db2 catalog tcpip node loopnd remote steel server 55460
    $ db2 catalog db sample as loopsam at node loopnd

    Sample database is a local database on the server.

    On the client:
    db2 catalog tcpip node loopndc remote steel server 55460
    db2 catalog db loopsam as loopsam at node loopndc

    Post-migration



    Upon the completion of database migration, performing one or all of the following tasks will greatly enhance your database and application performance:
    • Rebind all database packages after database migration

    All existing packages are required to rebuild under the newer DB2 release. This is not done as part of the database migration process. DB2 will automatically rebuild the package the first time it is being used, therefore there is a slight performance penalty paid for doing it. However, if you have a lot of packages in your database you may want to consider rebuilding them before they are first used. DB2 provides a command called DB2RBIND which can be used to rebuild all packages in the database.
    • Do RUNSTATS on tables

    All old statistics that are used to optimize query performance are retained in the catalogs during the database migration. Newer DB2 releases will have new or modified statistics. In order to take advantage of the new statistics, you may want to consider executing the RUNSTATS command on tables, particularly those tables that are critical to the performance of your SQL queries.
    • Tune up database configuration parameters

    Existing parameters may be updated and new parameters added with their default values during database migration. Some of the parameters may not be optimal for your applications. Therefore, you may want to consider fine tuning some of these parameters.

[{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Install\/Migrate\/Upgrade - Instance","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8;7","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
16 June 2018

UID

swg21156092

Page Feedback