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: 661

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.


Creating a function in DB2

Started by Jacob Ruchotzke in What's hot ? Jun 18. 0 Replies

With the help of our IT guy i have sort of gotten an example of how to create a function in our system. Can anyone help me with this? Please see the attached SQL file.Thanks in advanceContinue

Tags: function

Conversion of BLOB to String/ Text

Started by Jitesh Audichya in Application Development and DB2. Last reply by Jitesh Audichya Apr 24. 2 Replies

Hi All,Problem Statement:I have a field with BLOB data type in DB2 database, I want to extract this blob and convert it to Text. The text data after the conversion will be in Japanese characters. How can I write a select with the conversion from…Continue

Tags: on, DB2, conversion, text, to

© 2020   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service