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

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.

Forum

IDUG Db2 Tech Conference coming to San Paulo, Brazil and Mexico City! Register Now

Started by Surekha Parekh in What's hot ? on Thursday. 0 Replies

For the first time IDUG is hosting two events in Latin America. These seminars will bring together Db2 professionals from around the world for expert-led technical sessions and networking opportunities. This is your chance to connect! …Continue

Tags: Education

MSSQL linked server attaching to DB2 LUW

Started by Mike Jett in Application Development and DB2 on Thursday. 0 Replies

I am trying to create a linked server from MSSQL 2014  to DB2 11.1  I am able to create one linked server and get it to work with one DB.  I have not been able to figure out how to add additional catalogs(DB's).  Is it possible to use just one…Continue

Tags: server, linked

© 2019   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service