Make VPSEQT 100 XI-refresh feature delivered in PI59168 available for non-PGSTEAL-NONE pools or objects.

Dear Mark, We definitely understand the requirement to eliminate synchronous re-fetch of cached pages after a pseudo close. Note that this only occurs on pseudo closes which cause the pageset/partition to convert from GBP-dependent to Non GBP-dependent (i.e. not all pseudo closes, and in most cases a small minority). Nonetheless, we understand the impact. For PGSTEAL(NONE) buffer pools, APAR PI59168 should provide a solution. For Non PGSTEAL(NONE) buffer pools, we still don't have a solution. Most customers understand the rationale for removing the buffer pool scan logic in V10 (this logic caused significant CPU overhead as buffer pool sizes grew larger) - the tradeoff was that all cached pages belonging to the pageset/part were marked invalid for these psuedo close cases, sometimes causing an increase in synchronous I/O due to having to refresh these pages the next time they were referenced. This is a good tradeoff in almost all cases, but by eliminating a bigger problem we did cause a smaller problem. The proposed solution of "CLOSE NEVER" is a possibility, although there are some considerations that need to be carefully thought through. Pseudo Opened pagesets/parts are not candidates for physical close. So it could be possible to hit DSMAX and not have any datasets as physical close candidates because they are all pseudo opened and CLOSE NEVER. Also, ideally, we would like to reduce the number of knobs and complexity of the DDL and go towards a model where Db2 can automatically do the right thing without users needing to constantly tweak ever-more complex knobs. In this case, perhaps Db2 could automatically adjust an object to "CLOSE NEVER" behavior if we observe that it is negatively impacted by the increased synch I/O after pseudo close. This kind of a change could obviously impact recovery time for the object, so any "autonomics" along these lines would need to also take that into account.

Sincerely,

Db2 for z/OS Development

Thanks IBM. I understand how it would be difficult to identify specific candidate pages if not using PGSTEAL(NONE) and caching the entire object.

This still remains a challenge for us, so if you do determine a better way to eliminate the overhead of synchronous re-fetch after an XI, it would be greatly appreciated.

One such alternative may be this:

https://ibm-data-and-ai.ideas.aha.io/ideas/DB24ZOS-I-904

Thanks

-Mark

Dear Mark,

Thank you for submitting this Idea to the Db2 for z/OS team. We have reviewed it and found it to be a good idea, but it would be very difficult to implement, for reasons that would not be apparent to users.

The problem is that for non PGSTEAL(NONE) buffer pools, when a pageset is pseudo closed the pages get XI'd at the pageset level in a "bulk" operation, we avoid scanning the buffer pool (as of V10 and beyond) for performance reasons. So we have no way of knowing which pages were XI'd, and therefore which pages would need to be prefetched back into the BP after the pseudo close.

We appreciate your input to the Db2 for z/OS development team. We also hope that you will continue to submit ideas for improvements as customer feedback is a key component to shaping the future direction for Db2 for z/OS.

Sincerely,

Db2 for z/OS Development