Storage server device planning for Db2 for z/OS

Storage servers and Db2 for z/OS performance

An I/O subsystem typically consists of many storage disks, which are housed in storage servers such as the IBM® Storage DS8000® series. Storage servers provide increased functionality and performance over "just a bunch of disks" technology. Storage servers might use hard disk drives or solid-state flash drives. Many newer storage models are available with flash drive enclosures only.

The measure of disk speed in terms of RPM (revolutions per minute) for hard disk drives is relevant only if the cache hit ratio is low and the I/O rate is very high. If the I/O rate per disk is proportional to the disk size, small hard disks perform better than large hard disks. Large hard disks are very efficient for storing infrequently accessed data.

Flash drive enclosures are available with different capacity flash drives and performance. You can adjust the number of flash drive enclosures and device adapters to achieve high sequential bandwidth requirements and IOPS. Spreading the data across more disks is always better.

When I/O performance problems occur, especially when remote replication is involved, investigate the storage systems and communications network before looking for problems with the host database system.

Characteristics of storage servers

The following characteristics of storage server devices have the most affect on the performance of Db2 for z/OS.

• The size of the cache
• The number of channels and type of channels that are attached and online to a group of logical volumes, including high performance FICON®
• The size of non-volatile storage (NVS), if deferred write performance is a problem
• Disk arrays
• Advanced features such as Parallel Access Volumes (PAV), HyperPAV, Multiple Allegiance, and FlashCopy®
• Fast remote replication techniques

Storage servers and I/O channels

I/O channels are links for exchanging data between z/OS and external storage servers. With the availability of storage servers with all-flash drives and consolidation of storage servers, faster channel links and more channels might be necessary to meet your performance goals for Db2.

The IBM zSystems™ channel subsystem controls the I/O operation between the z/OS main storage and the external storage server. The channel subsystem can use one or more channel paths as a communication link to a storage server. The degree of I/O parallelism that can be sustained efficiently is largely a function of the number of channels.

High Performance FICON (zHPF)

In general, faster and more channels mean better performance. The recommendation is to use High Performance FICON (zHPF) protocol instead of FICON protocol when the storage server supports zHPF. You can activate zHPF by adding ZHPF=YES in SYS1.PARMLIB(IECIOSxx).

All Db2 I/Os are eligible for zHPF. zHPF protocol provides a significant reduction in channel usage compared to FICON. Channel usage reduction when using zHPF protocol improves both I/O rate (I/O per second) and bandwidth (Megabytes per second) performance.

zHyperLink

IBM zHyperLink is a short-distance point-to-point optical link between an IBM z14® or later system central processor complex (CPC) and an IBM Storage DS8000 series I/O bay.zHyperLink is designed for up to 10 times lower latency than zHPF. The maximum distance of the link is 150 meters. The low latency means that zHyperLink I/O can be synchronous to the CPU, and it eliminates the delays associated with asynchronous I/O. It complements zHPF to accelerate I/O requests.

Db2 for z/OS uses zHyperLink technology for synchronous database random read I/O and active log write I/O to reduce transaction latency time. To enable zHyperLink for Db2 I/Os, set the value of the ZHYPERLINK subsystem parameter value. Set this value to DATABASE for reads, ACTIVELOG for writes or ENABLE for both reads and writes. For more information, see DB2 zHyperLinks SCOPE field (ZHYPERLINK subsystem parameter).

Since zHyperLink is synchronous to the CPU, the CPU is spinning while it waits for the I/O to complete. While zHyperLink is active, the CPU spin time for synchronous database read I/O is accounted in Db2 class 2 CPU time and active log write I/O is charged to Db2 system services address space (ssnmMSTR) SRB time.

The zHyperLink I/O for active log write is eligible for processing on the IBM z Integrated Information Processor (zIIP). Therefore, before implementing zHyperLink for active log writes, plan for more zIIP processor capacity as needed to accommodate the increased zIIP usage.

For more information about the benefits and considerations when using zHyperLink technology for Db2 for z/OS, see Db2 13 for z/OS Performance Topics (IBM Redbooks).

Storage server features

IBM Storage servers offer the following features to further boost performance.

Extended address volumes (EAV)

With extended address volumes (EAV), you can store more data that is in VSAM data sets on a single volume than you can store on non-extended address volumes. The maximum amount of data that you can store in a single Db2 table space or index space is the same for extended and non-extended address volumes. The same Db2 data sets might use more space on extended address volumes than on non-extended address volumes because space allocations in the extended area are multiples of 21 cylinders on extended address volumes. When Db2 data sets can be allocated in the extended addressing space (EAS) of an extended address volume (EAV), this significantly reduces addressing footprint and ongoing management.

Parallel Access Volumes (PAV)

Parallel Access Volumes (PAV) enables multiple concurrent I/O operations on the same volume when the I/O requests originate from the same system. Parallel access volumes (PAV) make it possible to store multiple partitions on the same volume with almost no loss of performance. In older disk subsystems, if more than one partition is placed on the same volume, attempts to read the partitions result in contention. The contention shows up as I/O subsystem queue (IOSQ) time. Without PAVs, poor placement of a single data set can almost double the elapsed time of a parallel query.

PAV is used by z/OS to send parallel I/Os to the same volume. PAV can improve performance of large volumes. To implement PAV, alias volumes are defined within the same LCU as their corresponding base volumes. With PAV, the base-to-alias bindings are static. PAV can be enhanced by using HyperPAV which allows dynamic alias-to-base bindings to occur within one LCU.

PAV can be further enhanced by using SuperPAV, which is an extension of HyperPAV. SuperPAV uses aliases from similar LCUs of the same storage server in an on-demand fashion. Aliases are first selected from the home LCU. When no more aliases are available, they are borrowed from a peer LCU. Volumes in even LCUs can use aliases of other even LCUs and volumes in odd LCUs can use alias of other odd LCUs in the same storage server. Although the total LCU addresses are still limited to 256, you eventually have more than 256 addresses with SuperPAV because of the SuperPAV internal borrowing process.

You can ensure that at least HyperPAV is in effect, even if SuperPAV, is not available on the storage server by setting HYPERPAV=YES and HYPERPAV=XPAV in SYS1.PAMLIB(IECIOSxx).

Multiple allegiance

Enables multiple active concurrent I/O operations on a single device when the I/O requests originate from different hosts. In storage systems without multiple allegiances (except for the first I/O request), all requests to a shared volume are rejected, and the I/Os are queued in the IBM zSystems channel subsystem.

The requests are listed in Device Busy Delay and PEND time in the RMF DASD Activity reports. Multiple allegiances provide significant benefits for environments that are running a sysplex or IBM zSystems servers that are sharing data volumes. Parallel access volumes (PAVs) and multiple allegiance together dramatically improve I/O performance for parallel work on the same volume. These features nearly eliminate IOSQ and PEND time and lower elapsed time for transactions and queries.

FlashCopy

Provides for fast copying of full volumes. After an initialization period is complete, the logical copy is considered complete but the physical movement of the data is deferred.

Peer-to-Peer Remote Copy (PPRC)

Provide a faster method for recovering Db2 subsystems at a remote site in the event of a disaster at a local site. In a Metro Mirror PPRC environment, all writes are mirrored synchronously to a secondary device from the primary device which increases response time. zHyperWrite feature provides performance improvement by writing in parallel to both primary and secondary volumes. The primary and secondary volume must be in a HyperSwap relationship in PPRC for zHyperWrite to work. The Db2 subsystem parameter REMOTE_COPY_SW_ACCEL enables zHyperWrite for active log writes. zHyperWrite can substantially improve Db2 log write I/O latency in a metro mirror environment and thus improve transaction rate.

zHyperLink support is available for Metro Mirror. In this configuration all IBM Storage DS8000 series storage servers must be within 150 meters of the IBM zSystems system and connected through zHyperLink. FICON connectivity is still required as fallback if zHyperLink I/O fails. When zHyperLink is enabled in this configuration, zHyperWrite must be enabled

Other storage servers might offer similar capabilities.

Balancing the storage controller cache and buffer resources

Storage controller cache acts as a secondary buffer as data is moved between real storage and disk. Storing the same data in processor storage and the cache is not useful. IBM Storage DS8000 series and many other new storage servers use large caches and always pre-stage the data in the cache. You do not need to actively manage the cache in the storage server.

Having large memory resources for both Db2 buffers and storage controller cache in not often effective. In most cases, the recommendation is to invest in larger memory to improve performance.

When I/O cannot be avoided by using large buffer pools, use the maximum available storage controller cache size for performance gains. If the cache is substantially larger than the Db2 buffer pools, Db2 can make effective use of the cache to reduce I/O response time of random I/O. The storage caching algorithms are generally optimized for different workloads, such as sequential workloads and transaction-oriented random workloads, which might be active at the same time to improve I/O response time performance.

When IBM zHyperLink is enabled to complement zHPF for Db2 synchronous random reads, the I/O service time performance reduction is a function of storage server cache hit. zHyperLink read I/O is successful only when the requested data is in the storage server cache. Therefore, larger storage server cache can substantially boost the efficiency of zHyperLink read I/O.