This chapter reviews the major IBM database systems and the performance characteristics and considerations when they are used with the DS8000 storage system. This chapter describes the following databases:

You can obtain additional information about IBM Db2 and IMS at these websites:

This chapter includes the following topics:

The DS8000 storage family was designed to have a synergistic relationship with z/OS, Db2, and IMS which enables numerous performance benefits while providing ease of management for business as usual activities while providing ease of management for typical day-to-day business activities.

Configuring only two storage pools (one for CPC or Server 0; the other for CPC or Server 1) and leaving Easy Tier enabled to autonomically and dynamically enforce effective & efficient use of back-end resources; and, spreading Channel Path Groups across multiple DS8000 Host Adapters, will balance workload activity across the DS8000 resources.

Placing Db2 and IMS datasets using DFSMS (Data Facility Storage Management Subsystem) will ensure that data is placed appropriately using SMS constructs. Combining SMS and EasyTier leads to best of worlds approach where SMS is in control of the datasets and EasyTier looks after I/O activity. This tight integration allows for transparent and best in class service from a DS8000 perspective.

Db2 and IMS data sets can be allocated in the extended addressing space (EAS) of a extended address volume (EAV) to significantly reduce addressing footprint and ongoing management.

IMS Datasets such as:

Full Data set list can be reviewed at:

For more information on EAV volumes see: IBM DS8000 and IBM Z Synergy, REDP-5186-05

Db2 and IMS takes advantage of the parallel access volume (HyperPAV/SuperPAV) function that allows multiple I/Os to the same volume concurrently from applications that run on a z/OS system image. This will be helpful if IOSQ time is being experienced in the environment. At a minimum, HyperPAV should be enabled in a System Z environment with periodic checking of RMF reports to ascertain if more HyperPAV devices are required or SuperPAV functionality needs to be enabled.

For more information about IOSQ, see: “IOSQ time” on page 232.

For more information about HyperPAV/SuperPAV and enablement, see: IBM DS8000 and IBM Z Synergy, REDP-5186-05

High Performance FICON, also known as zHPF, is not new. It was introduced in 2009 and has seen multiple enhancements which has bought about significant performance improvements for Db2 and IMS I/Os.

The HPFEs in the DS8900F storage family deliver performance to such an extent that it leads to more stress on the channel subsystem on z Systems. zHPF in combination with flash provides an effective way to reduce this channel subsystem stress. zHPF should be enabled in the environment.

Latest versions of Db2 (Db2 v12) combined with zHPF and current FICON hardware (FICON Express cards 16S/16S+/16SA) deliver improvements to the following Db2 functions:

 

zHPF is enhanced to support Db2 list prefetch. The enhancements include a new cache optimization algorithm that can greatly improve performance and hardware efficiency. When combined with the latest releases of z/OS and Db2, it can demonstrate up to a 14x - 60x increase in sequential or batch-processing performance.

Db2 typically performs a maximum of two parallel list prefetch I/Os. With List Prefetch, zHPF sends a list of tracks in a Locate Record command followed by several read commands, which allows many parallel retrievals from disk. Also, the use of the Locate Record command now sends a list of non-contiguous records to prefetch, which increases the cache-hit rate for subsequent read commands.

In addition, Db2 can benefit from the new caching algorithm at the DS8900F level, which is called List Prefetch Optimizer (LPO).

For more information about list prefetch, see DB2 for z/OS and List Prefetch, REDP-4862.

In Db2, a castout refers to the process of writing pages from the group buffer pool to disk. Db2 writes long chains that typically contain multiple locate record domains. Traditionally, each I/O in the chain is synchronized individually. This process add to the response time and increases latency.

Now the DS8900F can be notified through the Db2 Media Manager that the multiple I/Os in a castout can be treated as a single logical I/O even though there are multiple embedded I/Os. In other words, the data hardening requirement is for the entire I/O chain. This enhancement brings significant response time reduction.

IBM FlashCopy (with all its options) can be used for:

With z/OS DFSMS copy pool setup and IBM Fast Replication Backup command FRBACKUP, database and storage administrators can create backup policies for IBM Db2 databases with minimum effect on applications. Db2 uses this function for Db2 system-level backup and to control the serialization effort that ensures a consistent set of the complete Db2 region (including all Db2 table space and logs). Furthermore, Db2 also maintains its repository, for example, by updating the bootstrap data set (BSDS) to reflect all backup activity. Similarly, for recovery DFSMS and IBM Fast Replication Restore command, FRRECOV enables restore of a complete Db2 region but also provides granularity of restoring an individual Db2 object from within the full system backup. The above is made possible due to the close synergy provided between DFSMS components, DFSMSdfp, DFSMShsm, DFSMSdss and Db2, all working together to provide a complete backup and restore package.

For more information about Copy Pools and setting them up in SMS, see:

Using FlashCopy with IMS enables cloning of entire IMS regions for testing purposes with minimal disruption. IMS Database utilities such as Database Image Copy, Online Database Image Copy, Database Recovery all use DFSMSdss to invoke the FlashCopy function. This allows for backup of a database or a subset of data at a point in time with minimum downtime for the database.

For more information see IMS High Performance Image Copy User’s Guide, SC19-2756-04.

In a synchronous replication (Metro Mirror) environment, all writes (including Db2 log writes) are mirrored synchronously to the secondary device, which increases transaction response times.

With zHyperWrite Db2 log writes are performed to the primary and secondary volumes in parallel, which reduces Db2 log write response times. Implementation of zHyperWrite requires that HyperSwap is enabled through either IBM Geographically Dispersed Parallel Sysplex® (IBM GDPS) or CSM. zHyperWrite combines Metro Mirror (PPRC) synchronous replication and software mirroring through media manager (DFSMS) to provide substantial improvements in Db2 log write latency.

For more information about zHyperWrite (z/OS and Db2 enablement and display), see:

The IMS WADS (write-ahead log data set) and OLDS (online log data set) are the most active data sets in an IMS environment as far as write activity is concerned. Because of its nature, the volumes that contain these data sets have the biggest challenge in the storage system. Due to the amount of I/O activity generated to the these volumes, it is strongly recommended to place these data sets on flash drives making the IBM DS8900F family the perfect storage system for this type of workload. It is also strongly recommended to allocate the WADS and OLDS across LCUs to try get the IO evenly balanced at the backend.

Furthermore, IMS v15.1 introduced the use of DFSMS Media Manager to write data to the WADS and OLDS. This change enables IMS to use important I/O features, such as zHPF, which increases I/O throughput, and zHyperWrite, which reduces latency time for synchronous replication.

The use of zHPF and zHyperWrite can be specially useful for data sets with high write rates, such as WADS and OLDS, which increases logging speed. Service times for WADS and OLDS can be reduced by up to 50%, depending on the environment setup.

For more information about zHyperWrite enablement, WADS and OLDS support for zHyperWrite, including migration considerations, see:

zHyperLink provides Ultra-low latency for database page reads in online transactions using synchronous I/O operations. Compared to a normal asynchronous I/O operation through FICON or zHPF, with zHyperLink there are no I/O interrupts or dispatcher delays. All the overhead associated with FICON and zHPF are avoided entirely leading to less than 20 microseconds of observed latency. This allows for processing of huge volumes of transactions at a much faster rate.

For more information about Db2 v12 enablement, see:

For more information about zHyperLink (z/OS enablement), see:

In a Metro Mirror environment, specifically for writes, both zHyperLink and zHyperWrite can be used together to further provide the benefits of reduced latency for reads (for all VSAM reads) and writes (Db2 v12 log writes and IMS v15 WADS/OLDS support).

For Dynamically changing zHyperLink eligibility of a dataset, see: