Hello David , " DB2 support also says set dump services to allow for 16Gb SVC dumps to accommodate DB2 "
Since you say 16 GB for SVC dumps , you should atleast have a minimum of 48 GB local page space to start with (that is 1:3 ratio ) When we had to increase MAXSPACE limit to 16 GB couple of months ago , this is what IBM recommended and i believe it is documented as well . Thanks , Roger On Friday, December 27, 2013 2:51 AM, "Jousma, David" <david.jou...@53.com> wrote: Hey Ron, Thanks for asking. Preventative measures mostly, trying to avoid aux storage shortage where possible. We did have a case last week on a DEV system where a DB2 user tried to use a large portion of their 4T MEMLIMIT, DB2 support also says set dump services to allow for 16Gb SVC dumps to accommodate DB2. Things are just getting larger it seems. Seems easier to do today when lpars have much more memory than they used to in the past and various components are using more memory. Like I mentioned before, we normally don’t page much, if at all. However there are those cases of bad coding, or poor decisions on a developer or dba's part. It's more of an insurance policy that there is ample to time evaluate a errant paging situation before getting to the point where address space create fails. We always have had an unused local page dataset laying around to do a PAGEADD in the event of a problem. I guess in my mind I was envisioning some sort of ROT that said allocate 1.5x(OR 2x, etc) local page capacity based on online memory. Since we haven’t evaluated local page space quantity since 2006 I thought maybe it was time they had a boost. I guess that’s not necessarily the case. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Hawkins Sent: Thursday, December 26, 2013 3:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local Page dataset sizing/quantity ROT? David, Perhaps with a different twist, what problems are you trying to prevent :-) I wouldn't go to the level of Controller separation anymore - it'd s bit of overkill. However I'd still look for some level of hardware separation within the controller to ensure paging runs as fast possible when you need it. Wide striping on EMC and HDS would make separate parity groups unnecessary, but consider Tier 1 or SSD for paging as you don't want it on the lowest tier when you need it. Also separate LCU, Channels, ports, and VSD for Hitachi Storage if you can. This things will optimize the speed of paging when you need it. Size is a question of the maximum number of slots you use when you page out, usually due to a dump. You may want to go back and look at how many slots you used the last few times dumping caused you to do some serious paging and size the locals to be 4 to 10 times the maximum slots used. In MXG parlance that would mean summing MAXUSED from TYPE75 for every interval, and then a proc univariate or means to see what shakes out. The idea here is to avoid AUX slot shortages. Have fun Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: Thursday, December 26, 2013 10:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Local Page dataset sizing/quantity ROT? > > Elardus, > > You are being a little tough on me today. Maybe your summer is too warm? > ;) > > See below > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Thursday, December 26, 2013 11:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Local Page dataset sizing/quantity ROT? > > Jousma, David wrote: > > >Hope everyone had a good holiday. > > What holiday? I don't see any holiday! ;-D ;-D ;-D ;-D >>Ouch. > > >Today we have a roughly 36GB of LOCAL page for each system, that was > setup in 2006 spread across 4 mod-9's. Back then we didn't have the amount > of memory on the processors that we have now, nor did we have DB2's using > data above the bar. Most of the systems in our sysplex have around 40Gb of > memory configured online. We have many more DB2 V10 instances active > now than we did in 2006. Without doing a lot of math and measurements, > I'm leaning towards giving each system between 80 and 100Gb's of local page > spread across 4 LOCAL page datasets for each system? We have dynamic > PAV's enabled. That would be 3-4 mod27's each. I could go with mod-54's, > at 2 per system, but not really sure how much the actual number of > virtual DASD devices even matters anymore? > > I think, you should say WHY are you asking? Performance issue? > Response time? Batch jobs doing 'query from hell'? Workload issue? > Other jobs / subsystems grabbing all memory? Anything else? > >> have the occasional job that causes problems, usually DB2 related. > > Just please define your 'system'. DB2 [sub] system or LPAR system? SysPlex? > >> 10-way parallel sysplex, 2-4 db2 subsystems on each lpar. > > For myself, I would go for 4 local page datasets distributed on at > least two different control units for DASD. Just try to spread your > paging out on more devices if you can do that. I would increase your > number 4 to 8 or more if that is possible in your environment. > > I'm just begging one or three questions: > > What is your DB2 priority in WLM? > >> No idea > > > Do you have any response time problems? > >> Not usually, in fact we don’t page much to begin with. > > > What is your LPAR / LPARS CPU/Memory limits? This could probably > raised and thus eliminate your paging problem? > >>I listed current memory configurations in original comments. There > >>are additional memory upgrades on the way. Most lpars have about > >>40Gb of memory configured online > > >Just trying to do the right thing. > > Probably not. ;-D It is really difficult to try to help you. I think > you should post your actual problem you're trying to solve. > > >>not really trying to solve any problem, just making sure things are > >>still set > correctly. Maybe *I* am erroneous in thinking that local paging > subsystem needs to some factor larger than installed physical memory. > > Groete / Greetings > Elardus Engelbrecht > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any > disclosure, copying, distribution or use of the contents of this > information is prohibited. Please reply to the message immediately by > informing the sender that the message was misdirected. After replying, please > erase it from your computer system. > Your assistance in correcting this error is appreciated. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
