Being as small shop you probably have one disk subsystem and one drive type for your production environment, so the drives will all perform the same no matter what storage class attributes are assigned. However, dataset striping can help, but you have to be selective about what datasets you strip.
So the question for you is this. Its it more cost effective to manage a static environment versus a dynamic environment? In the long run the static environment is going to be more costly, difficult-to-impossible to do effectively, and more prone to human error than a dynamic environment. PAVs, especially HyperPAVs, is the really way to go; without which you will be relegated to labor intensive performance and placement management and it will be difficult to grow past mod 3s. Also, can your next storage subsystem refresh have the drives striped across arrays? They would help significantly. The use of MIDAW will help some. On the labor intensive static configuration side, you could use DFSMS data separation (separation profile) to avoid allocation on the same controller. Add as many spare DASD volumes to the DB2 storage group as possible and spread the volumes across as many controllers as possible. Dataset striping can also help, depending on a number of factors. Your best investment would be some shrewd negations with your vendor to come to a reasonable price point for PAV and HyperPAV. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Neil Duffee Sent: Friday, September 18, 2009 11:52 AM To: IBM-MAIN@bama.ua.edu Subject: [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes I've just started some investigative reading but thought I'd toss the question out to the knowledge bearers in case someone's already contemplated/discarded the idea. Directions for better (finer? *grin*) manuals to start at are also helpful. I've been storage managing all DB2 regions except production for 2-3 years now with happy response from the DBA group. The delaying factor for production is the idea of Table/IndexSpace placement for performance reasons - primarily caused by UCB contention. We'd be considered a small shop by most with only 300 3390-3 volumes in the entire MonoPlex. (No PAV; rejected moons ago for cost) Production DB2 has 55 volumes assigned and 70 for all the others. The obvious method would be the use of Guaranteed Space but, to avoid the manual work required, I'm wondering about the MSR attributes for StorClas. The idea - good or bad - is that, by adding the performance attributes to the class and as the re-orgs progress, the heavily used datasets would end up by themselves since their volume would be less preferred by virtue of lower (relative to the rest of the pool) performance rates. Alternatively, when a heavy hitter is re-orged, a better volume would be selected that would likely not contain another heavyweight. The belief is that the system would slowly spread the datasets around to harmonize the performance rates over the entire pool without the need for manual intervention. Poor/mis-guided thinking? Discussion? (Some of the heavy hitters have already been partitioned to spread the problem around.) Another possible hitch in the process is my use of 1-2 Quiesced,New volumes in each pool combined with a Quiesced StorGrp for overflow. I don't believe that's a problem since SMS Status has a preferred value of 512 vs. 1 & 2 for MSR. Tks for all your time & considered opinions. ----------> signature = 6 lines follows <-------------- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee "How *do* you plan for something like that?" Guardian Bob, Reboot "For every action, there is an equal and opposite criticism." "Systems Programming: Guilty, until proven innocent" John Norgauer 2004 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
