Re: [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes
- From: Terry.Traylor@xxxxxxxxxx (Traylor, Terry)
- Date: 18 Sep 2009 12:32:02 -0700
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-MAIN@xxxxxxxxxxx] On
Behalf Of Neil Duffee
Sent: Friday, September 18, 2009 11:52 AM
To: IBM-MAIN@xxxxxxxxxxx
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 listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- References:
- [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes
- From: Neil Duffee
- [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes
- Prev by Date: IBM Program To Help Students Gain Critical Mainframe Skills Grows To More Than 600 Universities
- Next by Date: Re: DFSMS and Separation Profiles
- Previous by thread: [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes
- Next by thread: Re: [SMS] DB2 Table/IndexSpace managed placement vs. StorClas MSR attributes
- Index(es):
Relevant Pages
|
Loading
