DB2 Migration to Version 8

July 28, 2004

A long line of applying database FixPaks has ended with number 11, the last FixPak V7, and a brand new line has begun with DB2 V8. Currently, a total of six FixPaks have been released for DB2 V8. Consequently, support for DB2 V7 has come to an end. This event triggered many DBAs to begin the process of database migration to DB2 V8.

IBM promotional brochures stressed V8 superiority, with its brand new self-managing and resource tuning (SMART) database technology. Much was promised, including easy configuration, tuning and management with database-enhanced automation. However, before we can check it out, we have to upgrade our existing V7 databases.

This article is the first in a series demonstrating the migration procedure on the SUN Solaris operating system and a single node DB2 V7 database.

In the second article, I will provide practical solutions for important migration issues.

This article covers:

  • The Reasons for Migration
  • Preparation for Migration
  • Performing DB2 Configuration Backup and Data Backup
  • Migration from DB2 V7 to DB2 V8
  • Conclusion

The Reasons for Migration

There are several reasons why we should migrate to DB2 version 8. These are:

a.)   IBM's latest dessupport announcement

IBM withdraws support effective September 30, 2004, for the following products: 
                                                       Program
DB2(R) Content Management Product                      number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DB2 Universal Database(R) (UDB) V7.2 products
DB2 UDB Personal Edition                               5648-D45
DB2 UDB Workgroup Edition                              5648-D46
DB2 UDB Workgroup Unlimited Edition                    5648-D46
DB2 UDB Enterprise Edition                             5648-D48
DB2 UDB Enterprise -- Extended Edition                 5648-D50
Listing 1: IBM withdraw support announcement

b.)   The concern that arises from previously announced APARs (Authorized Program Analysis Report, a named issue with an IBM program, opened after the customer or IBM support personnel discover a problem with the database software code) or HIPER APARs ( HIgh Impact PERvasive APARs, critical DB2 bugs of which all customers should be aware.) such as:

c.) Some of the brand new database enhancements:

  • backup compression technique
  • restoring backup to system with different code page
  • table null and default values compression
  • online flush of database package cache
  • asymmetric index splitting with Index Type 2
  • uncommitted data evaluation via lock deferral
  • range-clustered table support (RCT)
  • online import mode
  • index renaming
  • point-in-time recovery supports a local time
  • online database check utility (INSPECT)
  • identity and sequences support in partitioned database environment

d.)   The existence of DB2 V8 Clients

IBM has provided client backward-compatibility with numerous restrictions. An official documentation describes this situation in the following way: "Due to significant communication protocol changes, you should be aware of some restrictions and limitations when accessing DB2 V7 servers from DB2 V8 clients."

These restrictions will not prevent the version 8 client from accessing the version 8 DB2 database, but will prevent usage of LOB, UDT and DATALINK data types, usage of authentification type SERVER_ENCRYPT, disable password changing, disable ATTACH command, two-phase commit, the SQL statements greater than 32 KB in size, .

Preparing for the Migration

My demo DB2 V7 database instance, used in this article, was running on the SUN Solaris 8 operating system, under instance owner db2inst1, hosting only one DB2 database "ARTIST" and having only one database partition.

Before migration, some minimum technical prerequisites must be satisfied.

a.)   System tablespace should have enough free space for double extension. This is very important, because running out of free space could interrupt the migration procedure and leave the database in an unusable state.

b.)   System temporary tablespace should have enough space for future expansion. A temporary tablespace was used during migration as intermediate storage for catalog tables, and a sort space for the index transformation.

c.)   The number of the log files and the log space should cover full change on the largest database object. According IBM, migration is fully recoverable, causing full transaction logging through the log buffer mechanism and the database log files. That is the reason why the database log configuration parameters should be extended. IBM recommends doubling the size for regular production parameters. After migration, database parameters have to be reset to those values used before migration.

d.)   Additional disk space requirements:

  • approx. 635 MB for DB2 V8 binary installation under /opt/IBM/db2/V8 directory
  • approx. 2GB for a temporary logging area under under /tmp/install directory. A DB2 installation is delivered in compressed format on the product CD-ROM. To install DB2, you need to copy the installation image to the temporary directory, uncompress it and perform the installation.
  • approx. 130MB for holding temporary trace files under /tmp directory







The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers