DB2 STOGROUP and SMS
Abe Salonga
STOGROUP and SMS in their production system? If so, how did you set it up?
Were there any problems that you encountered as far as how the two
facilities talk to each other?
Thank you in advance for your information.
Peter Schwarcz
Attached are some thoughts I had about SMS and DB2 data set placement that
might open up a healthy discussion on the topic.
I have been working in a shop where all of the DASD volumes are SMS managed,
but I have also ensured that the SMS pool has only DB2 application data sets
on it.
The first thing to do in order to control your own destiny in an SMS
environment is to turn the GUARANTEED SPACE attribute on for the SMS POOL.
Once the guaranteed space attribute is on SMS honours your space request to
the volume that you have specified in your stogroup.
I have created one stogroup per volume defined something like
CREATE STOGROUP SMS059 VOLUME(SMS059,"*")
so that in this example SMS059 is chosen first followed by any other volume
in my PRODDB SMS pool if I cannot find space on the primary volume.
That is the good news, but you get warnings in DB2 V3.1 that in future
releases of DB2 you will not be allowed to mix volume serial numbers with
the * notations, so we will have to go back to defining a list of preferred
volumes.
As for balancing the load across the DASD sub-system we run a GTF trace
occasionally for about 10 minutes during prime time and analyse the output
using an HDS cache analysis tool which helps identify long response times on
volumes as well as the particular data sets that are competing for
particular volumes.
I have also isolated my DB2 logs and work data base onto a separate SMS pool
so that we can turn DASD fast write on to the log volumes.
An allocation trick that I find useful for large DB2 tables that you know
will extend over 2Gb is to make the primary and secondary allocations about
300 cylinders and dedicate a STOGROUP to the large table. The effect of
using the 300 cylinders as primary and secondary is that you will have about
10 extents before a second data set is allocated ( and remember that the
primary allocation of the second data set is the same as the primary
allocation of the first data set) you should find that the extents are
contiguous on the dedicated volume.
Another area of concern in this whole game of DASD tuning is Channel
contention so make sure that you balance your DASD devices across multiple
channels.
The best IO is an IO that you do not have to do.
The more data that you can get into your buffer pools the less problems you
will have with DASD tuning especially now with DB2 V3.1 and above you can
come up with a scheme to isolate your CATALOG, DSNDB07, Table spaces and
indexes which all have different access patterns.
.-_|\ Peter Schwarcz
/ \ PO Box 225, Aireys Inlet, VIC 3231, Australia
\_.-._/ PHONE: 61-3-98822537 MOBILE 63-18-363938
v INTERNET: Peter_S...@IBM.NET
Sean A Dunn
A couple of add-ons of mine:
> I have created one stogroup per volume defined ...
- I do this, too, but have 1 stogroup defined only as '*' because there
are some datasets (particularly in development environments) where I
don't care where they go. This gives additional flexibility.
> CREATE STOGROUP SMS059 VOLUME(SMS059,"*")
- V4.1 does not allow mixed Stogroups so you will have to work-around this
sooner rather than later.
> I have also isolated my DB2 logs and work data base onto a separate SMS pool
> so that we can turn DASD fast write on to the log volumes.
- I include the BSDS copies on these. They get hit pretty hard.
> Another area of concern in this whole game of DASD tuning is Channel
> contention so make sure that you balance your DASD devices across multiple
> channels.
- We don't seem to have a problem with this. We are using the 3990-6's and they
are each capable of handling something like 4 3990-3 volumes going full-bore.
--
*** Sean Dunn, Wolverhampton, England ***
*** E-mail: se...@lilydale.demon.co.uk ***
Ruwu
we have only one SMS-StoGroup for all data except Catalog/Directory and
Sort-DB:
CREATE STOGROUP xxxxxx VOLUME("*")
with 80 3390-3.
The only disadvantages:
1. SMS does not care about a useful distribution of DB2-dataset (=
separation of indexes from their tables and separation of index- and
table-parts for //-IO). A CREATE or
LOAD REPLACE prefers to allocate everything on the same dasd.
2. all volumes tend to be equal filled => for new big spaces there is not
enough space on a single volume and the 1st Quantity will be split.
Maybe you can tune SMS to perform more intelligent, but I'm not SMS-man.
So I wrote a program to clean up, defrag, compact the dasds and distribute
data sets better. We ran it every weekend.
However, I do not see any disadvantage of an SMS-StoGroup against an
DB2-StoGroup.
So long,
Ruediger Wuepper / D-22299 Hamburg / Germany
Fax: Germany (0)40-512668
Russ Harrison
says...
>
>Does anyone have successful implementations of using the combination of
>STOGROUP and SMS in their production system? If so, how did you set it
up?
> Were there any problems that you encountered as far as how the two
>facilities talk to each other?
Yes, We implemented SMS with DB2 STOGROUPs. We changed our hardcoded
volumes in STOGROUPs to '*'s. During a transition time, We left the
volsers hardcoded in the STOGROUPs, but had the ACS routines pick up the
volser and route it to our 'online' SMS dasd pool as an "*".
We have not had any problems with the setup.
Russ Harrison
EDS
Russ Harrison
>Attached are some thoughts I had about SMS and DB2 data set placement
>that might open up a healthy discussion on the topic.
>
>I have been working in a shop where all of the DASD volumes are SMS
>managed, but I have also ensured that the SMS pool has only DB2
>application data sets on it.
>
I work in an environment where all DASD (with a few minor exceptions) are
SMS managed. We break into 3 pools (PERM,TEMP, and ONLINE). We put ALL of
our online data (TEST, PROD, DB2, IMS, VSAM/CICS) in the ONLINE pool. All
of my comments are based on this and elude to a pool of approximately
100+ volumes. We see SMS as the tool to get out of the dasd management
business for DBA's and DASD monitoring for our DASD support group. We
have been using this concept for about 3 years now. Of course we still do
DASD management and monitoring, but from the DBA side it is about 80%
less time.
>The first thing to do in order to control your own destiny in an SMS
>environment is to turn the GUARANTEED SPACE attribute on for the SMS
>POOL.
>
>Once the guaranteed space attribute is on SMS honours your space request
>to the volume that you have specified in your stogroup.
We only use guaranteed space for a few large IMS and DB2 files. Otherwise
SMS wouldn't be worth it. Guaranteed space used for everything is the
same as before SMS. I realize from talking to other DBA's we have taken
the radical approach.
>That is the good news, but you get warnings in DB2 V3.1 that in future
>releases of DB2 you will not be allowed to mix volume serial numbers
>with the * notations, so we will have to go back to defining a list of
>preferred volumes.
We have '*' in all of our STOGROUPS with one STOGROUP per Alias. We are
not there yet, but that is the standard.
>As for balancing the load across the DASD sub-system we run a GTF trace
>occasionally for about 10 minutes during prime time and analyse the
>output using an HDS cache analysis tool which helps identify long
>response times on volumes as well as the particular data sets that are
>competing for particular volumes.
>
>I have also isolated my DB2 logs and work data base onto a separate SMS
>pool so that we can turn DASD fast write on to the log volumes.
This is where we allow SMS tp place datasets across the pool as it
chooses. By having everything in the pool, we are mixing up low use
datasets with high used datasets, This essentially spreads out the I/O
across the pool. Highly used datasets are identified and forced to span
volumes to spread out the I/O and minimize the possibility of one volume
or channel getting all the activity. Also PROD datasets are in a MUST
CACHE storageclass and TEST is in a MAYBE CACHE storageclass, which can
be modified.
>The best IO is an IO that you do not have to do.
>
>The more data that you can get into your buffer pools the less problems
>you will have with DASD tuning especially now with DB2 V3.1 and above
>you can come up with a scheme to isolate your CATALOG, DSNDB07, Table
>spaces and indexes which all have different access patterns.
Agreed
Russ Harrison