Re: DB2 Data Bases and Central Storage

Lizette Koehler wrote:
Hi -

Has anyone been asked by their DB2 DBAs (or DB2 Sysprogs) on the MVS Mainframe what it would take to place their Tables into Storage? We are DB2 V8 nfm with z/OS V1.7 on a z9 and z860 systems.

Some of our DB2 folkes have been asking us and we cannot see why they would want to do that since we have physical constraints (ie. not a big enough iron).

If anyone has some ideas we as mvs sysprogs need to be aware should they do this, it would be helpful.

I am thinking ASM/SRM, Swapping rates, Page dataset usage, and possible looking at the coupler as we have data sharing set up. I am not sure how I would extrapolate out how much more memory would be needed, or page datasets, etc.

We really are not performance oriented here and get these kinds of crazy requests. Well maybe not crazy but rather not well thought out.

Elements that are easiy monitored and something I can place into an automation tool would be great.

Also if there are any other considerations that could make this work.

Lizette
(making bad code run faster...)


Did you mean a z890? What do you mean by not big enough iron? A z9 and a z890 are big boxes. IIRC the base memory on a z9 is 16GB.

I am also assuming you are talking about creating buffer pools large enough to fit the table into memory.

How much central storage do you have? What is your usage? Are you doing paging now? How big are the tables they want to put in storage? How much storage do you have in the coupling facilities?

We create a couple new 4K buffer pools, made them bigger than the 2 pools we were using and moved some of our heavest hitting index files and table spaces to these pools. We also enabled something that allowed DB2 to page fix something, I can't remember what it was allowed to page fix. Between the two changes we reduced our DB2 CPU usage by over 20%. I am not sure what that really amounted to, but I know we are on MULC for DB2 and it greatly reduced our cost for DB2.

You have to be carefull. Moving a table space into memory that randomly accessed may not be a great idea. In that case the index would be better suited to attempting to keep in memory.
.

Relevant Pages

  • Re: Theoretical Basis for SELECT FOR UPDATE
    ... but you DON'T need the full works of multi-versioning just to ... I imagine DB2 et al already have something like that?" ... > memory". ... >> can at least speculate on how it might be implemented. ...
    (comp.databases.theory)
  • Re: 4-way Opteron vs. Xeon-IBM X3 architecture
    ... >> is how you get to 128GB and AMD's specs talk of number of ranks of memory. ... >> clock speed has to be reduced with an obvious loss in bandwidth... ... they won't have as many problems with FSB speeds. ... most of the DB2 submissions are for AIX ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Real storage usage - a quick question
    ... So in the same vein if you want to say "More Memory!" ... host processor is an enabler for a lot of z/OS and DB2 exploitation. ... Behalf Of Tom Moulder ...
    (bit.listserv.ibm-main)
  • RE: MEMLIMIT and IEFUSI
    ... > I am not a DB2 person, but it would seem reasonable to me that IBM ... Data in memory is all about optimizing access. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)
  • Re: VSMLIST OWNCOMM DETAIL
    ... Is there a reason this cannot be tied to a DB2 address space that will clean ... It seemed that DB2 could just do the STORAGE OBTAIN and specify ... The system ignores the OWNER keyword ... > This apar is being closed USE. ...
    (bit.listserv.ibm-main)