DB2 Migration to Version 8

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
Marin Komadina
Marin Komadina
Marin was born June 27, 1968 in Zagreb, Croatia. He graduated in 1993 form The Faculty for Electrotechnology and Computer Sciences, University of Zagreb in Croatia. He started his professional career as a System specialist and DBA for the Croatian company Informatika System. His most important project was the development and implementation of the enterprise, distributed point of sales solution, based on the Oracle technology. In 1999, Marin became the company CTO, where he played an active role in company development and technical orientation. After Informatika System, Marin worked as an IT Manager Assistant for the Austrian international retail company "Segro," on location in Graz (Austria) and Zagreb (Croatia). He was responsible for the company's technical infrastructure and operational support. Segro used IBM technology, OS/400 operating system and DB2 database. In 1998, Marin joined the international telecommunication company VIPNet GSM that was a part of greater concern, Mobilkom Austria& Western Wireless Int. USA. After one year, Marin took over the IT System Manager position, where he managed many multi-platform, telecommunication projects and was leading the IT system department. In 2001, Marin started to work in Germany as a senior system architect. He is currently working for German banks on different banking projects.

Latest Articles