tag:blogger.com,1999:blog-6806654330436722244.post4641944880124922266..comments2024-03-24T17:11:57.814-07:00Comments on Catterall Consulting: Another Note on DB2 for z/OS Buffer Pool Page-FixingRobert Catterallhttp://www.blogger.com/profile/12629696535422235653noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-6806654330436722244.post-84764147589652069812010-03-11T19:10:22.438-08:002010-03-11T19:10:22.438-08:00A friend of mine in IBM's DB2 for z/OS develop...A friend of mine in IBM's DB2 for z/OS development organization rightly pointed out to me that in gauging the potential for CPU savings from a switch to PGFIX(YES) for a buffer pool, you should check the number of PAGES per second read into, and written out from, the buffer pool -- not the number of read and write I/O requests, as I suggested in my blog entry. What I had neglected to consider is the fact that, for a multi-page I/O operation (e.g., a prefetch read or a multi-page write), DB2 has to request the buffer fix and release actions FOR EACH PAGE INVOLVED IN THE I/O OPERATION. So, if 32 pages were read into a PGFIX(NO) buffer pool by way of a dynamic prefetch read, DB2 would have to make 32 requests of z/OS to fix in memory and then subsequently release the buffers to which the 32 pages brought in from disk are assigned. Thus it is that PGFIX(YES) can have a particularly beneficial effect for pools that have high levels of prefetch I/O activity.Robert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.com