Chris I think that's entirely possible, I am no DB2 person, but I have installed and configured tools for DB2 change data capture, DB2 to UDB, DB2 to SQL, and I think the DBA's at least my DBA's define the buffer pools larger for that purpose? I also have large frame area defined of 7740M
Carmen From: "Christopher Y. Blaicher" <[email protected]> To: [email protected] Sent: Tuesday, April 11, 2017 2:24:54 PM Subject: Re: Paging subsystems in the era of bigass memory It has been a while since I worked on DB2, but it is sounding like your buffer pools are too big. Consider this: DB2 will read a required page into 'new' buffer pool page before it will invalidate a page it already has in storage. Now we have a physical page in use. The system periodically comes around and looks at the UIC for a page and if it is high enough, it will page it out. Now we have a page on AUX storage. If DB2 doesn't need the data on that page, or doesn't need to use that page for a different data page, then that page just hangs out on AUX storage. I don't know what happens if you close a tablespace. DB2 probably just frees its logical use, but doesn't FREEMAIN the storage. Bottom line, you basically need enough AUX storage to hold all your buffer pools. If you have a lot of pages just hanging out in AUX and you don't have any demand paging, maybe you have buffer pools a little larger than you need. Of course, the DB2 guys want a minimum of reads because a read is much slower than a page-in, but that is something for individual shops to work out. Joel Goldstein can probably wax poetic on this topic much more than I can. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 2 Blue Hill Plaza #1563, Pearl River, NY 10965 P: 201-930-8234 | M: 512-627-3803 E: [email protected] www.syncsort.com CONNECTING BIG IRON TO BIG DATA -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jesse 1 Robinson Sent: Tuesday, April 11, 2017 2:47 PM To: [email protected] Subject: Re: Paging subsystems in the era of bigass memory The problem we face is 'paging creep'. Right after IPL, systems show 0% ASM usage for some period of time. Then usage starts to creep up until we get warnings, then eventually hit the no-more-SVC-dumps condition. Adding memory to an LPAR slows the creep but cannot seem to stop it altogether. The problem is most pronounced on systems with large DB2 apps. Part of the problem, I learned some time back at SHARE, is that there is no mechanism to 'reclaim' page slots that no longer need to remain on disk. Once storage gets paged out, it sits there like a sandbag until the owning task is stopped. Contrast that with JES2 spool track reclaim, which constantly munches through spool like Pacman and frees up unneeded space. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Conley Sent: Tuesday, April 11, 2017 11:13 AM To: [email protected] Subject: (External):Re: Paging subsystems in the era of bigass memory On 4/11/2017 1:16 PM, van der Grijn, Bart , B wrote: > Largest LPARs we have are about 200GB with 6 MOD27 per LPAR. They all run DB2 > for distributed workloads plus some application specific subsystems. > The two busiest of those LPARs each run one DB2 member of the same DB2 data > sharing group with a frame occupancy of about 39M. > Next to no paging. > > Bart > Bart, This is what has me puzzled. My two biggest users of AUX, according to TMONMVS, are our two DB2 production regions. They're like 90% of what's in the page datasets. I have the DB2 sysprog looking at DB2's virtual storage knobs to see if we have something misconfigured. Thanks, Tom Conley ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
