As more shops embark on the transition from DB2 Version 7 to V8, it’s time to review some of the biggest things to “keep an eye on” as you migrate your DB2 subsystems. DB2 V8 includes a substantial number of changes. With that in mind, let’s look at some of the biggest transition considerations.  Number 5—Do your homework: The single biggest cause of migration and post-migration problems is lack of upfront study and planning. Be sure to budget adequate time and resources. This includes training, time to read the “what’s new” documentation, and preparation of a thorough migration plan. 

Be sure to know the prerequisites and prepare your system for V8. This means knowing things such as you can migrate only from V7, you must be running on a zSeries box in 64-bit mode, and you need at least z/OS R3 (higher for certain features). Furthermore, you should understand the new modes of DB2 V8 (COMPAT, ENFM, and NFM), including how to migrate through the modes, what features are supported in each mode, and whether you can fall back in each mode. Your migration plan should include an estimate of how long you will run in each mode and how you will introduce the modes across your test, QA, and production systems.

Also, be sure to run the health check job, DSNTIJPM, provided by IBM to help you identify unsupported objects. If you want to prepare early, use job DSNTIJP8 from V7. It queries the catalog and identifies objects that will cause a migration failure.

Number 4—Bone up on CCSID issues: DB2 V8 requires you to provide a DSNHDECP module that specifies valid, non-zero CCSIDs for Single-Byte Character Sets (SBCS) for both EBCDIC and ASCII. CCSID stands for Coded Character Set Identifier, and is a unique value that identifies a code page.

The CCSID should be consistent across members of a data sharing group. Additionally, your terminal emulators should have a compatible code page—DB2 provides automatic conversion for remote access when needed. If your CCSID isn’t correct, character conversion will produce incorrect results. 

The DSNTIJPM health check job will check for various CCSID problems, but there can be others. Be sure to check workstations and emulator software for other CCSIDs. 

Number 3—Be ready for Unicode: Unicode is an issue for V8 because the DB2 catalog is converted to Unicode in DB2 and most internal DB2 processing is done in Unicode. This includes literal parsing, utility parsing, program  preparation, optimization, authorization, internal names, special registers, and tracing. You will need to prepare your environment to support Unicode. But don’t worry too much, as you don’t have to convert your application data to Unicode (of course, you can if you wish).

Unicode provides a unique number for every character, no matter what the platform, program, or language. Unicode is a modern standard for character encoding; it’s the foundation for the globalization of data storage and access because it handles just about any symbol you will encounter.

Number 2—Be prepared for performance issues: Just running DB2 V8 means there’s additional work to be performed, due to factors such as increased code size, 64-bit address translation, and increased module linkage costs. IBM’s stated performance objective is less than 10 percent average CPU regression—when comparing V7 and V8 subsystems with the same size buffer pools, hardware, workload, and so on. 

Real storage requirements can also increase by at least 10 percent as compared to V7. On migration to V8, buffer pools move above the 2GB bar—and the new limit for virtual buffer pools is 1TB (instead of 1.6GB). Additionally, the EDM pool, RID pool, SORT pool, and compression dictionaries are stored above the 2GB bar; the IRLM is moved above the 2GB bar, too (with PC=NO no longer supported). So, be ready to deal with increased memory usage requirements.

Of course, once you get to NFM you can take advantage of new features to improve performance, such as more Stage 1 predicates, MQTs with AQR, multi-row INSERT and FETCH, distribution stats, backward index scan, volatile tables, and so on. So, IBM taketh away, but they also giveth! 

Number 1—Know those new features: Of course, the biggest reason to migrate to V8 is to take advantage of the new features. Most tool vendors are introducing phased support for V8, so keep track of your vendors to make sure they support the new V8 features when you need them. Features that seem to be later in the support cycle include support for 4,096 partitions, multi-level security, sequence objects, and MQTs.