IBM Db2 - The Ultimate Database for Cloud, Analytics & Mobile
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).
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.
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.
Add a Comment