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

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.

User Groups

Blog Posts

Retrieval of current DSNZPARM and DSNHDECP settings

Posted by Peter Hartmann on July 16, 2019 at 8:04 2 Comments

History:

With DB2 Version 9.1 for z/OS a new system supplied stored procedure…

Continue

Videos

  • Add Videos
  • View All

IDUG Conference News

PlanetDB2.com [Latest Blogs from the Biggest Names in DB2]

© 2019   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service