tag:blogger.com,1999:blog-6806654330436722244.post2937824170564508727..comments2024-03-24T17:11:57.814-07:00Comments on Catterall Consulting: A Note on DB2 for z/OS Page-Fixed Buffer PoolsRobert Catterallhttp://www.blogger.com/profile/12629696535422235653noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-6806654330436722244.post-4611759147634878082011-09-21T14:55:10.131-07:002011-09-21T14:55:10.131-07:00Thanks for your response and explanation. Much ap...Thanks for your response and explanation. Much appreciated!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-11708797459794967002011-09-21T13:21:53.245-07:002011-09-21T13:21:53.245-07:00Well, assuming that your z/OS LPAR's memory re...Well, assuming that your z/OS LPAR's memory resource isn't under too much pressure (i.e., the demand paging rate during busy processing times is less than 10 per second), there is not a reason I can see for not page-fixing the buffers of a pool dedicated to the sort work table spaces. That said, this is usually not going to be a big win because (in my experience, at least) that pool is usually not going to have as high a level of disk I/O activity as some of the pools used for user table spaces and indexes (and the higher a pool's disk I/O rate, the greater the CPU benefit of buffer page-fixing). I'm usually inclined to recommend page-fixing the buffers of the pools with the highest levels of disk read and write I/O activity, whilst leaving the other buffer pools with non-page-fixed buffers (this to provide a "safety valve" should the z/OS LPAR's memory resource unexpectedly come under a lot of pressure, leaving z/OS with a need to do some page-out work).Robert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-34018675623993158152011-09-21T11:48:36.626-07:002011-09-21T11:48:36.626-07:00Yes, that's correct.Yes, that's correct.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-6986439325977635382011-09-21T11:07:15.350-07:002011-09-21T11:07:15.350-07:00By "sort pools," are you referring to a ...By "sort pools," are you referring to a buffer pool dedicated to the DB2 work file table spaces in database DSNDB07?Robert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-84060634312998193412011-09-21T07:17:48.542-07:002011-09-21T07:17:48.542-07:00Is there any reason not to page fix sort pools?Is there any reason not to page fix sort pools?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-90129689408249386822011-02-10T15:55:11.948-08:002011-02-10T15:55:11.948-08:00Perhaps a misuse of the term V=R on my part. I did...Perhaps a misuse of the term V=R on my part. I did not mean to imply that virtual storage addresses are equal to real storage addresses for page-fixed buffer pools. I meant to point out that for a page-fixed buffer pool, the amount of real storage occupied by the pool (at least, by the pool's buffers) would be equal to the virtual storage consumed by the pool, because the contents of the page frames used by the pool would be fixed in server memory, as opposed to being eligible for page-out to auxiliary storage. So, a pool with 10,000 page-fixed 4K buffers would occupy 40 MB of real storage and 40 MB of virtual storage.<br /><br />That said, you're right. I did use V=R in a way that does not agree with the technical meaning of the phrase. Good catch!Robert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-17269968307609111122011-02-09T07:40:27.295-08:002011-02-09T07:40:27.295-08:00Just so noone misunderstand, V=R is Virtual addres...Just so noone misunderstand, V=R is Virtual addresse = Real addresse, not so much to do with page fixing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-37206747821414455572009-12-15T06:05:19.091-08:002009-12-15T06:05:19.091-08:00My pleasure. Glad you found the information to be ...My pleasure. Glad you found the information to be useful. Thanks for the positive feedback.<br /><br />RobertRobert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-41492495655135422792009-12-15T01:33:33.086-08:002009-12-15T01:33:33.086-08:00Very useful post explaining background of the page...Very useful post explaining background of the page fixing process that can't be found in the standard DB2 documentation.<br />Thanks!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-41065903221407161332008-07-28T09:23:00.000-07:002008-07-28T09:23:00.000-07:00The CPU efficiency (in terms of CPU consumption re...The CPU efficiency (in terms of CPU consumption relative to the number of rows returned to requesters) of the DB2 for z/OS-based data warehouse with which I have been working (in a consulting capacity) has improved substantially, but the page-fixing of buffer pools is one of several tuning steps that have been taken in that environment (there have also been some database design changes), and we do not have figures that isolate the effect of page-fixed buffers.<BR/><BR/>In a presentation delivered at the May, 2008 International DB2 Users Group North American Conference by Dr. Jim Teng of IBM's DB2 for z/OS development organization, it is mentioned that page-fixing DB2 buffer pools can result in "up to 10% CPU saving."<BR/><BR/>This and other IDUG conference presentations can be accessed in the member area of the IDUG Web site at www.idug.org. Basic IDUG membership is free, and premier membership is available for a modest annual fee (or through attending an IDUG event).Robert Catterallhttps://www.blogger.com/profile/12629696535422235653noreply@blogger.comtag:blogger.com,1999:blog-6806654330436722244.post-79550920838487878162008-07-20T01:54:00.000-07:002008-07-20T01:54:00.000-07:00dear robert,have you any empirical data to share ?...dear robert,<BR/><BR/>have you any empirical data to share ?<BR/>and benchmarks/test results ?<BR/><BR/>because in your post, you have said nothing that can't be found in the standard documentation...<BR/><BR/>tAnonymousnoreply@blogger.com