z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Partitioning table spaces

z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
SC23-6866-00

Partitioned table spaces permit large tables to be split into smaller entities which are managed more easily using DB2 utilities. Operations such as IMAGE COPY and REORG are more efficient and consume less total aggregate processing time when performed on smaller entities when tables are larger than 2 GB.

Partitioned table spaces are recommended when:
  • Tables become very large
  • Data might be relatively static for long periods of time
  • DB2 maintenance must be minimized
  • Any combination of these reasons

Backup and recovery actions for DB2 tables and table spaces are necessary under all circumstances. Regular IMAGE COPY operations and proper safeguard of DB2 logging is necessary to provide contingency for outages of any type.

Reorganizing tables is a different matter. Under circumstances where an object table or object directory table can be managed at a stable total allocation, segmented table spaces nearly eliminate any need to reorganize tables using the REORG operation. OAM uses DB2 indexes for all SELECTs and INSERTs as a consequence of its underlying design. The use of indexes removes the requirement for the tables to be in strict cluster index order. When a table is relatively new and is loaded with data, the RUNSTATS utility should be used to be certain that DB2 has good information on the order within the table in its catalog tables. Following RUNSTATS, a BIND with the EXPLAIN parameter should be performed to determine if DB2 is using the indexes. After this initial use of RUNSTATS, avoid the further use of the RUNSTATS utility. Over time with deletes of older objects and reuse of space for new objects, the object directory and object tables tend not to be in strict cluster sequence. It is not important that OAM object and object directory tables be in cluster sequence and regularly reorganized. OAM access to data is entirely though DB2 indexes. The initial "decision" by DB2 to use indexes when a table is created is maintained, and indexes are used for access, as long as RUNSTATS utility is not used when tables are not maintained in cluster index sequence. The use of RUNSTATS without reorganizing a table could result in DB2 discontinuing use of indexes.

The advantages described here are best used when segmented table spaces are used for objects and object directory entries. As stated, simple table spaces should not be used for OAM. There are circumstances when the INSERT performance differences between segmented and partitioned table spaces are not as important as minimizing the work load of DB2 maintenance activity. It is the decision of the installation whether to accept less possible performance and use partitioned table spaces based on their unique operating circumstances.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014