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

Summary and recommendations
Migration from V7 to V8 CM takes from 0.2 to 10 minutes depending on the size of the catalog
and directory (medium to large). Before the catalog migration, it is recommended that you
clean up your catalog doing a MODIFY on all table spaces: The result will be a cleanup on the
SYSCOPY.SYSLGRNX entries. It is also useful to free the old version of packages that are
not being used any more.
Note: When you execute a MODIFY, do not forget to take a look at the tables that will be in
copy pending, because your application might not be expecting the DB2 return code.
Reorg Catalog and Directory before migrating to NFM.
Migration from V8 CM to V8 NFM takes from 0.1 to 2 hours depending on the size of the
catalog and directory (medium to large). The longest step is the catalog reorg DSNTIJNE,
and the execution of that job can be divided.
The size of the catalog, both data and index, has been observed to increase between 1% and
10%.
Online REORG SHRLEVEL REFERENCE of SPT01 and 17 catalog tables is the most
time-consuming component. A very rough Rule-of-Thumb on estimating the time for a
medium to large catalog and directory in non-data sharing is:
6 min. + 3 to 7 min. per GB of SPT01, SYSPKAGE, SYSDBASE, etc.
The time is heavily dependent on the DASD and channel model used.
Allocate larger work files for online REORG of large tables such as SYSDBASE, SYSPKAGE.
Allocate work files on separate DASDs, LCUs for online REORG of tables with parallel
sort/build indexes such as SYSHIST, SYSPKAGE, SYSSTATS, and SPT01.
9.5 Catalog consistency query DSNTESQ
The DSNTESQ sample job is provided to DB2 users so that they can check the consistency
of their DB2 catalogs. This sample job consists of DDL, INSERT and 65 queries to verify the
integrity of the catalogs and directories. The SQL can be run from SPUFI or DSNTEP2 and
contains DDL which creates copies of the catalog using segmented table spaces. In some
cases, the queries in DSNTESQ run faster when run on copies of the catalog instead of the
actual catalog because the copies have additional indexes.
Some of these catalog consistency queries can run for extended periods of time on
subsystems with large amounts of catalog data. In order to improve the performance of most
of these DSNTESQ catalog consistency queries, they were rewritten to use non correlated
subqueries on table columns that are in index keys.
In the past, some queries in DSNTESQ have had very poor performance. In DB2 V6, a
customer introduced a subset of queries rewritten from DSNTESQ which performed very well
against IBM supplied DSNTESQ queries. In DB2 V8, some queries from DSNTESQ were
rewritten for performance and retrofitted to DB2 V7. On Table 9-7 we have an example of
retrofitted queries followed by other rewritten queries.
Table 9-5 Queries 5 and 18 rewritten for better performance
Query (DB2 V8 - New Function Mode) Old (V8 NFM) New (V8 NFM)
Chapter 9. Installation and migration 359