DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

2.1 Overview of major impact items
2.1.1 DB2 catalog
2.1.2 CPU
There is a tremendous amount of new function available in DB2 V8. Like any release, there
are things you really like and things you like less. And the things you like come at some cost.
In this chapter we present a realistic perspective of DB2 V8 for you: The good and the not so
good. Certainly, adding new function implies adding instructions, and it becomes more and
more difficult to contain the increase in path length. The performance department at Silicon
Valley Lab, along with DB2 development, tries to minimize the overhead you can incur with
each new release. This is especially true with V8 because of the large amount of additional
code.
It is important that you are aware of the effect DB2 V8 has on components of DB2, such as
DB2 catalog, CPU growth, virtual storage, real storage, compatibility mode, and new-function
mode. The more educated and informed you are before migrating to DB2 V8, the easier the
planning becomes. The migration is simplified by avoiding known pitfalls. The migration goal
is a smooth and successful implementation and you can concentrate on exploiting the new
functions.
Important: Remember that you can only migrate to DB2 V8 from DB2 V7. It is possible to
migrate to DB2 V7 from DB2 V5 by a skip release migration. However, skip release
migration is not generally supported, including migration to V8.
We now begin to discuss the components of DB2 V8.
In DB2 V8, much of the character data in the DB2 catalog changes to the Unicode encoding
scheme. This does not mean you have to change all your EBCDIC or ASCII data to Unicode.
The catalog conversion to Unicode allows you to support Unicode object names and literals.
But it does require that you, before migrating to DB2 V8, implement z/OS Conversion
Services for your environment, and this requires an IPL.
Most character columns in the DB2 catalog are converted to Unicode VARCHAR(128), and
there is typically a 1 to 10% increase in the space used. If you have any user-defined indexes
defined on the catalog, you may want to drop them before V8. Afterwards, you can redefine
these indexes and specify them as NOT PADDED. If you do not drop these indexes, the
default is PADDED and these user-defined indexes grow considerably, since many columns in
the index grow often from 10 to 128 bytes. For this reason, DB2 V8 allows variable length
keys (VARCHAR(128)) in an index.
We anticipate that there may be some growth in the size of the DB2 catalog once you migrate.
However, it really depends on a number of factors. Some installations never or infrequently
perform a reorganization of the DB2 catalog. For them, the difference in size after migration
may be negligible. For those who REORG on a regular basis, they can see up to a 10%
increase in the size of the DB2 catalog.
For details regarding the effect of Unicode on the DB2 catalog and directory, refer to 9.1.2,
“Unicode parsing” on page 342.
In the past, as you migrated from one release of DB2 to the next, the typical increase was not
more than a 5% CPU cost. In fact, staying under 5% has been the target of DB2 development.
We estimate that there is four times more code in V8 than in V7, and some CPU increase is
Chapter 2. Performance overview 11