Appendix H. Reorganizing the DB2 Catalog

IN THIS APPENDIX

• When Should the DB2 Catalog and Directory Be Reorganized?

Prior to DB2 V4, it was not possible to reorganize the table spaces in the DB2 Catalog and DB2 Directory because of the internal hash and link structures built into these databases. But for DB2 V4 and later releases, you can expediently reorganize the DB2 catalog and DB2 directory in a systematic manner using the REORG utility.

The DB2 catalog is the central repository for DB2 object and user metadata. DB2 is constantly referring to that metadata as it processes applications and queries. The physical condition of the table spaces and indexes that comprise the DB2 catalog is therefore a major component in overall DB2 subsystem performance.

Likewise, the DB2 directory contains internal control structures such as DBDs and skeleton cursor tables that can be accessed only by DB2 itself. The information in the DB2 directory is critical for database access, utility processing, plan and package execution, and logging. Efficient access to this information is quite critical.

Prior to DB2 V4, the only option for any type of "reorganization" activity was to run the RECOVER INDEX utility on DB2 catalog indexes. This rebuilt the indexes, but had no impact on the underlying data housed in the actual physical table space. Catalog reorganization is permitted on table spaces and indexes in the DB2 catalog database ( DSNDB06 ) and on specific table spaces ( SCT02 , SPT01 , and DBD01 ) in the DB2 directory database ( DSNDB01 ). As of DB2 V6, of course, the REBUILD INDEX utility can be run to rebuild DB2 Catalog and Directory indexes.