The DB2 Catalog Gets a Makeover

3 Pages

When DB2 10 for z/OS arrives, it will usher in a host of enhancements to both the DB2 catalog and directory. This article addresses how to prepare for migration and details of all the new or improved enhancements. Note that since IBM hasn’t yet announced the Generally Available (GA) date for DB2 10, some things covered here could change, and the timing of this article means it can’t cover every possible new feature or change.

Preparing for Migration

Before getting into the DB2 10 enhancement details, let’s first discuss how to prepare to make all these changes. During your catalog migration to DB2 10 Conversion Mode (CM), there are two “optional” activities you should perform. Both steps validate the migration worthiness of the catalog and really aren’t optional.

The first optional job step, Migration Step 2, runs the standalone DB2 utility DSN1CHKR, checking the five catalog table spaces that use links and one directory table space that uses hashes for broken links, broken hash chains, and orphans. These catalog and directory table spaces will have their links and hashes removed while being converted to universal table spaces during the Enabling New Function Mode (ENFM) process. The ENFM conversion process can only be more successful knowing that the inputs to the conversion are clear of problems.

Also during this job step, DSN1COPY with the CHECK option should be run against all catalog and directory table spaces. This will verify that all the catalog and directory table space pages are physically correct and that the catalog table spaces are clustered. DB2 should be stopped (or, at a minimum, have all activity disabled), while you run DSN1CHKR and DSN1COPY to avoid errors caused by some catalog or directory pages still being in the buffer pools. Both of these standalone utilities run against the disk copy of the data only and aren’t aware of any pages in the buffer pools. 

Finally, the third optional job in Migration Step 2 you should run is the CHECK INDEX utility for all DB2 catalog and directory indexes. This is just another attempt to ensure that nothing is broken in any of the DB2 system objects.

The second optional step that shouldn’t be skipped or ignored is Migration Step 4. A set of queries in member DSNTESQ in SDSNSAMP can be used to verify the logical correctness of the catalog tables. Although you can run these queries with SQL Processing Using File Input (SPUFI) or DSNTEP2, you should use DSNTEP2 so you can retain a record of the outputs.

The migration process requires an image copy of the catalog and directory. Having a backup of all the catalog and directory table spaces is critical to ensure recoverability to a previous version of DB2. Don’t take chances with your catalog and directory by skipping this step.  

DFSMS Mandatory

Data Facility Storage Management System (DFSMS) made its debut back in 1993 and there are still DB2 professionals unwilling to use it with DB2. They’ve even had incentives; every release of DB2 adds a few more features dependent on DFSMS. But now, DB2 10 may have come up with the biggest incentive of all. DFSMS, or DB2-managed storage, is mandatory before a DB2 10 upgrade or new installation can even be considered, before even getting to CM.

3 Pages