Q and A

Asked and Answered

I inherited a reasonably large DB2 subsystem that exclusively uses user defined/user managed storage. As you know, once you start managing hundreds of DASD volumes manually, even with homegrown reports, the situation gets out of hand quickly. I want to lead the way to more efficient use of our DBA's time by moving on to SMS or STOGROUP-based storage definition. I know of some shops that define one STOGROUP for each volume and add an "overflow" volume every 10 volumes. My experience is that STOGROUP are not very good at spreading data out. Do you use — or would you recommend using — STOGROUPS in conjunction with SMS by using the VOLUME('*') parameter in the STOGROUP definition and letting SMS do the actual placing?

Robert Catterall responds:

We do in fact use DB2-managed data sets, and we let SMS manage placement of the data sets via the specification of VOLUMES('*') in our STOGROUP definitions. This is done for user tablespaces and indexes — we still manage system data sets, such as the active log data sets, manually. The approach has worked well for us, in that we get excellent DB2 I/O response times from our disk subsystem (and it's a pretty demanding environment, with peak CICS-DB2 transaction rates in excess of 900 per second).

We take a very simple approach, in that we have one SMS storage group for all our user tablespaces and indexes in the production DB2 environment. Some people like to have one SMS storage group for tablespaces, and another for index data sets. We haven't done that, because the one big SMS storage group works fine for us, and we like to keep things simple when we can.

See a complete archive of reader/author Q&As .