DB2 performance is very sensitive to buffer pool paging so they should be backed by real memory and not over allocated. You will more likely hear from upset users before demand paging hits the "significant" threshold. Depending on the number of pages being fixed the effect can be severe. HTH Mohammad
On Wed, 20 May 2009 09:23:23 -0500, Ken Hansen <khhwk...@comcast.net> wrote: > >My apologies if this topic has been addressed recently. I have not been >able to get to this server for some time. > >My DB2 folks are wanting to increase the size of their buffer pools and do >some page fixing in memory (real storage). I am told that they already have >allocated some 7.3 gb of buffer pool space and in order to add more, we will >be needing to procure another 8gb of storage. > >But when I look a real storage metrics, I see UICs at 2540 and minimal >demand paging rates even at the most constrained times. Local page data sets >are measuring at 26% busy at times, but that can be rectified by adding >more. > >I am also being told that we will soon be doing page fixing, and that will >result in sever constraint on the available memory. > >Am I right in thinking that I should see significant demand paging and lower >UICs ? Or are these metrics blind to page fixing and buffer pool size >changes ? > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html