Asynchronous cross-invalidation (XI) for coupling facility (CF) cache structures, e.g. Db2 for z/OS group buffer pools (GBP)

Description of the new feature:

When Db2 in a data sharing environment writes a changed page to the GBP the same page in the buffer pool(s) of the other member(s) must be invalidated to avoid back level data access in this/these member(s). This invalidation is done by the cross invalidation (XI) feature which is a key functionality of data sharing and controlled by coupling facility control code and XES.

Since beginning of data sharing this XI invalidation is synchronous. With the following prerequisites it can now be asynchronous:

- GBP is on a CF with CFLEVEL 23 or higher

- z/OS V2.2 or V2.3 with OA54688

- Db2 12 for z/OS with PH10577 (and PH05193). These APARS describe some technical details, like monitoring (DSNB818I message) and restriction (32K pages). PH10577 lifts the restriction for row level locking (RLL).


To consider:

The benefit is that transactions do not need to wait until this invalidation process has completed.

The following should be considered for this asynchronous processing:

1) The build-up of this asynchronous environment must be cheaper than the invalidation itself otherwise there is more overhead than before. This is nothing special for this feature but is always the challenge for such a re-design.

2) The time to invalidate the buffer in the other member(s) is a function of the distance between coupling facility and the other member(s).

Internal IBM measurements show that the benefit is visible already with zero distance (~7%) and increases for long distances, e.g. 10 km up to ~21%.

These numbers apply to accounting class 2 elapsed times.

3) At lock release time (e.g. COMMIT or Page P-Lock release) Db2 must ensure that the XIs are done: this is done by appropriate sync-up calls.

Batch workload with reasonable commit frequency is one workload which benefits.

Business impact:

The benefit for customers is mainly improved response time due to the elapsed time improvement.

This is achieved by

- keeping the CPU consumption equal. The removal of the CPU spinning during GBP write saves CPU, but the sync-up calls consumes CPU. Consider that these GBP writes are mostly zIIP eligible.

- keeping the CF utilization on the same level, although the sync-up calls generate additional GBP requests.

The internal IBM measurements back both statements.

Views: 512

Add a Comment

You need to be a member of The World of DB2 to add comments!

Join The World of DB2

Bringing Db2 enthusiasts together virtually. Expert or novice, distributed or mainframe, this is the place for everything DB2.


NEW Announcement! Db2 Analytics Accelerator Version 7.5

Started by Patricia Zakhar in What's hot ? Oct 15. 0 Replies

Today, IBM announced the Db2 Analytics Accelerator for z/OS Version 7.5, which delivers enterprise-grade transactional and analytic processing. It introduces Integrated Synchronization, a transformative capability that provides an integrated,…Continue

Export Data from DB2 5.0 Database from a Laptop

Started by Rakesh in Application Development and DB2 Oct 8. 0 Replies

Dear All,   I've to Export Data out from DB2 5.0 Database from a Laptop. I've installed Toad for DB2 on that Laptop. Now going to Install DB2OLEDBV5_x64 on that Laptop. After this how to proceed?ThanksRakeshContinue

Tags: Export, 5, DB2

© 2019   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service