Too many STOGROUPs

Bill M

Too many STOGROUPs
How many STOGROUPs are too many? I have 12 DB2s (3 production and 9
non-production) and each DB2 has 32 STOGROUPs defined. My DB2 (v8) runs
under z/OS 1.8. The DB2s average close to 500G each and growing.
This seems excessive since it constantly requires monitoring to make sure
adequate amounts of DASD are allocated to the storage groups so they do not
run out of space. I did not set this up.
Would it make more sense to have only one storage group per DB2 and just
throw DASD into them and let DB2/SMS manage this?
I have also seen recommendations that 3 STOGROUPS are adequate, one for each
of the following:
1) DB2 Catalog and Directory objects
2) BSDS and active log data sets (required for BACKUP/RESTORE)
3) DB2 user data

Also, the DASD volumes are all defined as 3390-3 (residing on a DS8000).
Would it also make sense to migrate to higher-capacity 3390s (mod-9,27 and
54) so I don't have to worry about as many volumes?

Any insight is appreciated.
bill

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldnt fault anything. Very impressed."
_____________________________________________________________________

Cathy Taddei

Re: Too many STOGROUPs
(in response to Bill M)
Hi Bill. If by stogroup you mean SMS storage group (as opposed to DB2-defined stogroup), then yes, you have too many. Way too many. I personally agree with the 3 storage group recommendation that you outlined, but we have condensed it even more. Here are the 4 SMS storage groups we use:

1) Prod catalog, directory, BSDS, logs for our one production data sharing group
2) Prod user tablespaces
3) Test catalog, directory, BSDS, logs for all 4 non-prod data sharing groups
4) Test user tablespaces for all 4 non-prod data sharing groups

We used to have a lot more, but we got a new storage manager who simply doesn't have time to bother with managing all that dasd, and life has been much easier ever since.

If and when I decide to put my archive logs on DASD, I'll probably want a separate storage group for them.

I do dink around with dataset placement to separate my active logs and such, but that's probably not necessary, since with our EMC dasd architecture I can't guarantee anything really being on separate volumes, and with our huge cache it wouldn't matter anyway.

Regards,
Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Bill M
Sent: Tuesday, September 29, 2009 10:19 AM
To: [login to unmask email]
Subject: [DB2-L] Too many STOGROUPs

How many STOGROUPs are too many? I have 12 DB2s (3 production and 9
non-production) and each DB2 has 32 STOGROUPs defined. My DB2 (v8) runs
under z/OS 1.8. The DB2s average close to 500G each and growing.
This seems excessive since it constantly requires monitoring to make sure
adequate amounts of DASD are allocated to the storage groups so they do not
run out of space. I did not set this up.
Would it make more sense to have only one storage group per DB2 and just
throw DASD into them and let DB2/SMS manage this?
I have also seen recommendations that 3 STOGROUPS are adequate, one for each
of the following:
1) DB2 Catalog and Directory objects
2) BSDS and active log data sets (required for BACKUP/RESTORE)
3) DB2 user data

Also, the DASD volumes are all defined as 3390-3 (residing on a DS8000).
Would it also make sense to migrate to higher-capacity 3390s (mod-9,27 and
54) so I don't have to worry about as many volumes?

Any insight is appreciated.
bill



------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

======

Philip Sevetson

Re: Too many STOGROUPs
(in response to Cathy Taddei)
Bill,

Ther are many questions you have to deal with to make a decision here.

* How big are your largest tables?

* Do you have tablespaces created with DSSIZE in excess of 2GB?

* Is MVS Extended Addressing enabled (see your zOS Sysprog), so that you can have datasets larger than 2GB?

* What is your backup and Disaster Recovery strategy?

* Are there any application or backup dependencies on you having small packs?

* Are your packs' freespaces notably fragmented? (Larger packs tend to have larger chunks of freespace available, but take longer to defragment when the freespace is mostly eaten up.)

* Do you have different packs for all your applications, is that part of your backup strategy?

The answers to the above will all influence your DASD design strategy and any migration-to-larger-volumes which you undertake.

Most installations I've worked at are currently using a mix of 3390-9 and larger volumes, with system/catalog datasets residing on smaller volumes and application data and workfiles on larger. This reduces the number of volume addresses used by z/OS, which I'm given to understand makes for easier administration and better z/OS performance. Also, larger volumes and more up-to-date zOS versions allow larger (and therefore fewer) physical extents, which also improves performance.

--Phil Sevetson

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Bill M
Sent: Tuesday, September 29, 2009 1:19 PM
To: [login to unmask email]
Subject: [DB2-L] Too many STOGROUPs

How many STOGROUPs are too many? I have 12 DB2s (3 production and 9
non-production) and each DB2 has 32 STOGROUPs defined. My DB2 (v8) runs
under z/OS 1.8. The DB2s average close to 500G each and growing.
This seems excessive since it constantly requires monitoring to make sure
adequate amounts of DASD are allocated to the storage groups so they do not
run out of space. I did not set this up.
Would it make more sense to have only one storage group per DB2 and just
throw DASD into them and let DB2/SMS manage this?
I have also seen recommendations that 3 STOGROUPS are adequate, one for each
of the following:
1) DB2 Catalog and Directory objects
2) BSDS and active log data sets (required for BACKUP/RESTORE)
3) DB2 user data

Also, the DASD volumes are all defined as 3390-3 (residing on a DS8000).
Would it also make sense to migrate to higher-capacity 3390s (mod-9,27 and
54) so I don't have to worry about as many volumes?

Any insight is appreciated.
bill

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldn�t fault anything. Very impressed."
_____________________________________________________________________

Mike Bell

Re: Too many STOGROUPs
(in response to Philip Sevetson)
32 stogroups is a LOT. I would suspect something like each stogroup has a
different high level qualifer and usercat so someone can bill for dasd
utilization. I would start by identifying how many of the DB2 stogroups are
used.

Second - just because you have 32 DB2 stogroups does not require that you
have 32 SMS stogroups. You can consolidate the DB2 user stogroups into many
less SMS storage groups. I would suggest a long discussion with whoever
maintains SMS.

The only requirement for segregation of DB2 application data is whether you
want all your DB2 datasets to be EA ie capable of dssize > 4G. Most of the
people I talk to have a dedicated stogroup for 'large' objects where large
depends on your environment.

The last item is simple - do not mix production and test data on the same
volume. When you do DR, you don't have to deal with the test data.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Bill M
Sent: Tuesday, September 29, 2009 12:19 PM
To: [login to unmask email]
Subject: [DB2-L] Too many STOGROUPs

How many STOGROUPs are too many? I have 12 DB2s (3 production and 9
non-production) and each DB2 has 32 STOGROUPs defined. My DB2 (v8) runs
under z/OS 1.8. The DB2s average close to 500G each and growing.
This seems excessive since it constantly requires monitoring to make sure
adequate amounts of DASD are allocated to the storage groups so they do not
run out of space. I did not set this up.
Would it make more sense to have only one storage group per DB2 and just
throw DASD into them and let DB2/SMS manage this?
I have also seen recommendations that 3 STOGROUPS are adequate, one for each
of the following:
1) DB2 Catalog and Directory objects
2) BSDS and active log data sets (required for BACKUP/RESTORE)
3) DB2 user data

Also, the DASD volumes are all defined as 3390-3 (residing on a DS8000).
Would it also make sense to migrate to higher-capacity 3390s (mod-9,27 and
54) so I don't have to worry about as many volumes?

Any insight is appreciated.
bill

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldnt fault anything. Very impressed."
_____________________________________________________________________

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldn’t fault anything. Very impressed."
_____________________________________________________________________

Roger Hecq

Re: Too many STOGROUPs
(in response to Mike Bell)
Without commenting on why you have 32 STOGROUPS, I would strongly
recommend that you follow Mike Bell's suggestion that you use SMS
managed storage groups. This will simplify your life significantly.


Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Bill M
Sent: Tuesday, September 29, 2009 1:19 PM
To: [login to unmask email]
Subject: [DB2-L] Too many STOGROUPs

How many STOGROUPs are too many? I have 12 DB2s (3 production and 9
non-production) and each DB2 has 32 STOGROUPs defined. My DB2 (v8) runs
under z/OS 1.8. The DB2s average close to 500G each and growing.
This seems excessive since it constantly requires monitoring to make
sure adequate amounts of DASD are allocated to the storage groups so
they do not run out of space. I did not set this up.
Would it make more sense to have only one storage group per DB2 and just
throw DASD into them and let DB2/SMS manage this?
I have also seen recommendations that 3 STOGROUPS are adequate, one for
each of the following:
1) DB2 Catalog and Directory objects
2) BSDS and active log data sets (required for BACKUP/RESTORE)
3) DB2 user data

Also, the DASD volumes are all defined as 3390-3 (residing on a DS8000).
Would it also make sense to migrate to higher-capacity 3390s (mod-9,27
and
54) so I don't have to worry about as many volumes?

Any insight is appreciated.
bill

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldnt fault anything. Very impressed."
_____________________________________________________________________
Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.


UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.

_____________________________________________________________________

* IDUG 09 Rome, Italy * October 5-9, 2009 * http://IDUG.ORG/EU *

_____________________________________________________________________

IDUG Europe Attendee Testimonial-
"Conference was superb! Couldn’t fault anything. Very impressed."
_____________________________________________________________________

Roy Reynolds

Re: Too many STOGROUPs
(in response to Roger Hecq)
I agree with Mike and Roger and Cathy,
My approach has been to segregate by subsystem using STOGROUP SYSDEFLT
having the vcat name the same as the SSID. Beyond that I use sms to
segregate the catalog, logs, bsds from application data. Yes, large objects
are also segregated usng SMS but the HLQs are all the same for each
subsystem. And yes, DataSharing introduces some variation for the
member-specific tablespaces.

I don't allow non-prod objects in my prod subsystems. Since the mid 1990's,
I ensured subsystem backup/recovery was easy. One HLQ did the trick when
coupled with ACS routines. These days SMS/DB2 collaboration makes all this
so much easier.

I have seen many companies standards manuals state 'never use STOGROUP
SYSDEFLT'. I don't agree. I wonder if this is a carryover from the VCAT
user-defined VSAM dataset days.
These days, recovery of an application is so much easier that relying on a
unique application HLQ seems out-of-date. I'd really avoid an application
recovery of any sort outside of DB2's control. However, restoring an entire
non-data-sharing subsystem is easy.

I can also imagine some sites wanted to control dataset placement using
STOGROUPs but these days SMS does a much better job at that.

What are the considerations for varying STOGROUP? I'd like to hear your
ideas based on current DB2 and z/OS capability.
thanks,
Roy

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L