DB2 Cast Out Accelerator

 

Is the performance of DB2 Cast Out Writes causing you headaches?  Have you tried the DB2 Cast Out Accelerator? 

 

DB2 for z/OS uses z System coupling technology to cache data into group buffer pools (GBP) located inside the coupling facility.  There are times when the group buffer pools need to be vacated very quickly and the data written out to the database on DASD:  

 

1.   Hardware failures that cause a loss of connectivity from one or more members of the Sysplex to a coupling facility requires that the structures in the coupling facility be rebuilt.

2.   Planned reconfiguration operations that will change the size of a structure, prepare for disruptive maintenance, add/removal of a coupling facility, load balancing, performance management and avoiding single points of failure.

3.   DB2 group buffer pool exhaustion possibly caused by heavy update activity such as batch or from performing a DB2 REORG

 

The new IBM DS8000 Cast Out Accelerator provided by the DS8880 allows z/OS to construct new I/O requests that can be accelerated by the storage system. 

 

For a typical DB2 cast-out write operation that transfers 64 dis-contiguous 4k pages, internal lab experiments show as much as a 46% reduction in response time with a complimentary increase of 81% in throughput when compared to performance of the same I/O operation prior to the DB2 Cast Out Accelerator function.   Even more impressive is Metro-Mirror (MM) performance behavior for same I/O operation.  Lab experiments for Metro-Mirror revealed a 75% reduction in response time while delivering 280% (2.8x) more throughput compared to the performance of the same I/O operation without the DB2 Cast Out Accelerator function.    The performance results are published in white paper, IBM System Storage DS8880 Performance Whitepaper (February 2017), Document Number WP102605.

 

Cast out elapsed time is critical for resilience.  If cast out falls behind, and the GBP starts filling up with changed pages, then this can cause application delays because DB2 will begin to throttle the writes of new pages to the GBP.  Also, if a CF-related failure or planned outage were to happen while the GBP is in this state (lots of changed pages), then the GBP recovery/rebuilt times can be significant elongated, which can extend outage time.  The DB2 data sharing design requires cast out to work efficiently, otherwise clients may see performance impacts, or possibly elongated outages.

 

The DB2 Cast Out Accelerator enhancement is an exclusive z Systems/DS8880 leadership function. Additionally, other Media Manager applications such as ZFS and PDSE that do long chains of discontiguous/scattered writes can also benefit from this code enhancement. Finally, this is a zHPF only function that is available by default starting with R8.1 License Internal Code on all DS8880 models. The System z Media Manager support is provided in APAR OA49684 for z/OS releases 1.13, 2.1, and 2.2. 

Join The Discussion

Your email address will not be published. Required fields are marked *