Objectives

This section discusses the setup we used to make sure we could see the impact of our changes in the disk I/O layer on the throughput.

A database is a very intelligent mechanism that speeds up access to data, especially by using caches in an optimized way. To ensure that we see the impact of our changes in the disk I/O layer on the throughput, it was necessary for the workload to run in a disk I/O dependent mode, with lower cache hit ratios. When most of the data came from the caches, it was clear that changes in the underlying disk I/O subsystem might have only a moderate to no impact on the transactional throughput rates. Therefore, the requirement was that the total disk I/O throughput (read + write) was at least 100 MiB/sec. This was reached by reducing the SGA (decreasing the cache hit ratios) and scaling the amount of user.

A known issue with ECKD devices is the 'subchannel busy' issue. Due to the ECKD channel protocol requirements a disk (subchannel) is considered as busy, which means blocked, when one channel program (I/O request) is active. In database environments this leads to the effect that parallel executed I/O requests (which is very typical for these environments) to the same disk get queued. This can become a severe bottle neck. It becomes even more relevant the larger the single disk is, and the higher the amount of parallel running I/O processes is. The solution here is to use PAV or HyperPAV devices. For this reason we used mod27 DASD devices instead of mod9 devices to ensure that this effect really impacts our environment.

Another interesting setup topic is whether it matters if database logs and data are mixed in the same disk devices (same ASM disk group). And finally we tried to identify performance relevant setup parameters for ECKD and FCP devices.

We tried to make the FCP setup as close as possible to the ECKD setup.