Migration Challenges

6 Pages

As you run migration jobs, your DB2 subsystem is transformed from one mode to the next. The first stop is CM. This is reached after running multiple jobs culminating in DSNTIJTC (Tailor Catalog), which runs the CatMaint program.

Several things have happened in CM:

  • Running V8 code: DB2 is now running V8 executables except for code that performs any functions new to V8. More on this later.
  • New utility functions are available: Utilities such as REORG and Image Copy are now in V8, including any new functionality, parameters, and performance benefits. (Exception: BACKUP SYSTEM and RECOVER SYSTEM aren’t available.)
  • Parser now processes Unicode data: All SQL must be converted (if necessary) to Unicode before it can be parsed.
  • New access paths are available: Binds of SQL statements can now take advantage of new join methods and new access paths.
  • There are some control blocks above the 2GB bar: Portions of the EDM Pool (Database Drivers [DBDs] and dynamic statement cache) have moved above the 2GB bar, providing virtual storage constraint relief.
  • DRDA requestors can use multi-row processing: This applies mostly to dynamic SQL arriving from Distributed Relational Database Architecture (DRDA) requestors through Distributed Data Facility (DDF). They can use multi-row fetch, insert, and update functions, which can provide significant CPU savings. (Static SQL multi-row processing isn’t available until you’re in NFM.)
  • Page fixing for virtual pools exists: Virtual pools can now be page-fixed. This creates some CPU savings, as DB2 no longer must release and regain storage for these pools.

Compatibility Mode Issues

In CM, issues generally fall into these categories:

  • CPU increases
  • Code page and character set issues
  • Data sharing “mixed mode”
  • Access path regression.

CPU Issues

Some shops have seen a significant increase in CPU usage after migrating to CM. Among several possible reasons for this are changes in the way Task Control Block (TCB) and Service Request Block (SRB) CPU times are now charged to various address spaces.

Most CPU-related issues arise because:

  • Much of the DB2 code now runs in 64-bit mode.
  • The parser requires conversion to and from Unicode.
  • Indexes now allow variable-length keys.

SQL processing and access to tables and indexes occur in the DBM1 address space. In V8, the DBM1 address space runs in 64-bit mode; the code uses 64- bit instructions. The instructions are “wider,” memory addresses are longer, and executable modules are somewhat larger. There are more “bytes” of executable code, resulting in somewhat longer path lengths.

Some CPU is now used in converting data to Unicode. In addition, the index-handling code has been greatly expanded to handle potentially variable- length keys.

IBM provides materials explaining what kinds of environments may experience CPU regression and these are documented on the IBM support Website.

6 Pages