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 *