DB2 & IMS

IMS High Availability Large Databases (HALDBs) offer many advantages, including virtually unlimited space and the promise of near-continuous availability. HALDBs give you an opportunity to review existing IMS database reorganization strategies because you can reorganize one or more partitions while the other partitions are still online and available for processing. This article reviews database maintenance best practices for HALDBs and is geared toward an audience already familiar with the concepts of HALDB.

What to Reorganize

Reorganization is a necessary evil for all IMS database types, including an HALDB. Before deciding what to reorganize, it’s important to determine why an HALDB needs reorganization. Because HALDBs can be huge, it can take a long time and significant resources to reorganize all partitions. An HALDB might need to be reorganized to:

  • Improve performance
  • Address insufficient space in one or more partitions
  • Reduce the number of partitions
  • Make randomizer or other partition-level parameter changes
  • Make structural or other Database Description (DBD)-level changes
  • Rebalance the entire HALDB.

Independent Software Vendor (ISV) tools make the maintenance process easier by monitoring HALDBs, identifying partitions that need reorganization, and recommending the appropriate solutions.

Improve Performance

Reorganizing partitions to improve performance is the simplest reorganization scenario. You can perform a traditional, multi-step reorganization on one partition or any subset of partitions. During the reorganization, other partitions are available for updates. The HALDB Online Reorganization (OLR) function can be used in this scenario, and it keeps the partition available for updates during the reorganization process, thus increasing your data availability. During the OLR process every database record is moved—hence logged—so you should plan for extra logging. Because all records are moved during an OLR process, consider the recovery time necessary after an OLR completes. An image copy isn’t necessary after an OLR process, but consider how long you can go before you must take an image copy of the partition to meet recovery Service-Level Agreements (SLAs). ISV tools let you complete the reorganization of individual partitions in a single step with minimal or no outage. ISV tools also allow for intelligent online reorganizations that don’t require reading, rewriting, and logging the entire partition.

Insufficient Space

Each HALDB partition is limited to 4GB of data. As the data grows and a partition approaches the 4GB limit, you can rebalance the data across adjacent partitions or split an existing partition into multiple, new partitions. When rebalancing the data across adjacent partitions, it’s important to identify all the affected partitions and include them in the reorganization process. As soon as the high key definitions are changed in the RECONs, the Partition INIT Needed flag is turned on for all affected parts. If all partitions haven’t been unloaded, there’s the potential for data loss. For example, assume you have three partitions with these key ranges:

PARTAA: High Key 22222

PARTAB: High Key 44444

4 Pages