SMS for DB2 Infrastructure

Larry yozwiak

SMS for DB2 Infrastructure


We are considering converting our DB2 Z/os V8 infrastructure datasets to be
SMS managed – this includes 18 test/systest subsystems and 12 production
subsystems – across 10 lpars. This is in preparation for DB2 V10 (We know
that it is not necessary to convert before V10 but wanted to rid ourselves
of managing the private volumes that we have today).

In various IBM manuals we have seen that 3 storage groups are recommended:
1 for the catalog and directory, 1 for the BSDS and active logs and a third
for DB2 application data. Our DASD group is trying to convince us that
separate SMS storage pools are unnecessary and we should put the catalog,
directory, BSDS and logs into the same SMS pool as the application
databases. Their contention is that with todays technology (DS8000 model
8700) our non-SMS volumes (used today for infrastructure) are just virtual
volumes stripped across very large physical drives so that in reality our
infrastructure datasets are today currently mixed in with everything anyway
and trying to separate them into separate SMS pools is unnecessary. We do
have separate DB2 application database pools for production and test with
different migration strategies and ACS routines will be enhanced to further
differentiate migration strategies for archive logs etc.

Our questions:
1.What are other shops doing and what might have you done differently now
that you're using SMS?
2. If we have no intention of ever using BACKUP/RESTORE SYSTEM
functionality, is there any reason (recovery, performance or future
capabilities) that would prevent us from using the same SMS pools for both
DB2 infrastructure and DB2 application datasets?

I monitor the list with a condensed version once a day so if you ask me any
questions, I can’t respond quickly.

Thanks for your thoughts.

ITG Enterprise Infrastructure
DB2 for Z/os Infrastructure
Voice: 570 585 3147
Email: [login to unmask email]
The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Daniel Luksetich

Re: SMS for DB2 Infrastructure
(in response to Larry yozwiak)
Most places I've been to do the split you describe. One reason is to
assure researved space (logically) for the system objects. Some shops set
up two storage groups, system and application.

I recommend that you split logs and BSDS across different DS8000
subsystems. You can do this using SMS. These days when you have a failure
it is typically catastrophic and impacts an entire DASD subsystem. If both
sets of BSDS/LOGS are in the same DASD subsystem such a failure can render
the subsystem non-restartable and you'll have to cold start. That means
lost data. If you can tollerate lost data then that is not an issue. And
the answer is yes, I have seen this type of failure, and no the logs and
bsds were not split, and yes we did loose data.

Cheers,
Dan

On Wed, 12 Jan 2011 10:33:36 -0500, [login to unmask email] wrote:
> We are considering converting our DB2 Z/os V8 infrastructure datasets to
be
> SMS managed – this includes 18 test/systest subsystems and 12 production
> subsystems – across 10 lpars. This is in preparation for DB2 V10 (We
know
> that it is not necessary to convert before V10 but wanted to rid
ourselves
> of managing the private volumes that we have today).
>
> In various IBM manuals we have seen that 3 storage groups are
recommended:
> 1 for the catalog and directory, 1 for the BSDS and active logs and a
third
> for DB2 application data. Our DASD group is trying to convince us that
> separate SMS storage pools are unnecessary and we should put the
catalog,
> directory, BSDS and logs into the same SMS pool as the application
> databases. Their contention is that with todays technology (DS8000 model
> 8700) our non-SMS volumes (used today for infrastructure) are just
virtual
> volumes stripped across very large physical drives so that in reality
our
> infrastructure datasets are today currently mixed in with everything
anyway
> and trying to separate them into separate SMS pools is unnecessary. We
do
> have separate DB2 application database pools for production and test
with
> different migration strategies and ACS routines will be enhanced to
further
> differentiate migration strategies for archive logs etc.
>
> Our questions:
> 1.What are other shops doing and what might have you done differently
now
> that you're using SMS?
> 2. If we have no intention of ever using BACKUP/RESTORE SYSTEM
> functionality, is there any reason (recovery, performance or future
> capabilities) that would prevent us from using the same SMS pools for
both
> DB2 infrastructure and DB2 application datasets?
>
> I monitor the list with a condensed version once a day so if you ask me
any
> questions, I can’t respond quickly.
>
> Thanks for your thoughts.
>
> ITG Enterprise Infrastructure
> DB2 for Z/os Infrastructure
> Voice: 570 585 3147
> Email: [login to unmask email]
> The information contained in this message may be CONFIDENTIAL and is for
> the intended addressee only. Any unauthorized use, dissemination of the
> information, or copying of this message is prohibited. If you are not
the
> intended addressee, please notify the sender immediately and delete this
> message.
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * Your only source for independent, unbiased, and trusted DB2
> information. *
> ** The best DB2 technical sessions in the world
> ** Independent, not-for-profit, User Run - the IDUG difference!
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is
> the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

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

Max Scarpa

Re: SMS for DB2 Infrastructure
(in response to Daniel Luksetich)
It's the usual battle of DB2 DBA/Sysprog Vs Dasd Manager, When I managed
DASDs I was used to split data/indexes (for management resons) leaving
system object in dedicated (SMS) volumes putting BSDSs, logs and some
catalog tables in different DASDs belonging to different arrays.
Dan is right when he says now the main DASD failure involve the entire
disk subsystem (microcode error mainly as all is redundant in modern
machines, literature has many cases) and for this reason it can difficult
to achieve if you have only one dasd machine (as it was in my last
company) or machine dedicated to DB2 is 'THAT machine, dot'.
You can plan to use a mirror machine (if you're doing DR with remote data
replication) in case of disaster (and it can be considere a disaster), in
this case it'd be a fault-tolerant subsystem even if you've BSDS/Logs in
the same controller/machine/whatever.

For sure DASD managers don't like too many exceptions in their ACS
routines and sometime a too 'simple' standard naming doesn't help as well
to manage these exceptions. For some hints see John Iczkovits' papers
(SHARE, various proceedings). And to destroy a DB2 subsystem DASD isn't
the only danger, see for instance: I. Yassin 'When hell breaks loose'
IDUG EU 2009.

Just some useless thoughts.

Max Scarpa

Certified hopeless case DB2 sysprog




_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

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

Cathy Taddei

Re: SMS for DB2 Infrastructure
(in response to Max Scarpa)
We use a single storage group for catalog, directory, BSDS, logs, work space, and DSNDB04 (which we strongly discourage people from using). Another storage group is for application tablespaces, plan tables, and vendor tools.

Cathy

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of [login to unmask email]
Sent: Wednesday, January 12, 2011 7:34 AM
To: [login to unmask email]
Subject: [DB2-L] SMS for DB2 Infrastructure


We are considering converting our DB2 Z/os V8 infrastructure datasets to be SMS managed – this includes 18 test/systest subsystems and 12 production subsystems – across 10 lpars. This is in preparation for DB2 V10 (We know that it is not necessary to convert before V10 but wanted to rid ourselves of managing the private volumes that we have today).

In various IBM manuals we have seen that 3 storage groups are recommended: 1 for the catalog and directory, 1 for the BSDS and active logs and a third for DB2 application data. Our DASD group is trying to convince us that separate SMS storage pools are unnecessary and we should put the catalog, directory, BSDS and logs into the same SMS pool as the application databases. Their contention is that with todays technology (DS8000 model 8700) our non-SMS volumes (used today for infrastructure) are just virtual volumes stripped across very large physical drives so that in reality our infrastructure datasets are today currently mixed in with everything anyway and trying to separate them into separate SMS pools is unnecessary. We do have separate DB2 application database pools for production and test with different migration strategies and ACS routines will be enhanced to further differentiate migration strategies for archive logs etc.

Our questions:
1.What are other shops doing and what might have you done differently now that you're using SMS?
2. If we have no intention of ever using BACKUP/RESTORE SYSTEM functionality, is there any reason (recovery, performance or future capabilities) that would prevent us from using the same SMS pools for both DB2 infrastructure and DB2 application datasets?

I monitor the list with a condensed version once a day so if you ask me any questions, I can’t respond quickly.

Thanks for your thoughts.

ITG Enterprise Infrastructure
DB2 for Z/os Infrastructure
Voice: 570 585 3147
Email: [login to unmask email]

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.

________________________________

[ http://www.idug.org/images/banners/idug_2011.gif ] < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

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

John Amsden

Re: SMS for DB2 Infrastructure
(in response to Cathy Taddei)
We separate our datasets primarily by "production" and "non-production".
We do this only because we
use "snap" technology for our disaster recovery. We have had no issues
pertaining to mixing catalogs,
tablespaces, indexes, etc.


________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of
Taddei, Cathy
Sent: Thursday, January 13, 2011 12:20 PM
To: [login to unmask email]
Subject: Re: [DB2-L] SMS for DB2 Infrastructure



We use a single storage group for catalog, directory, BSDS,
logs, work space, and DSNDB04 (which we strongly discourage people from
using). Another storage group is for application tablespaces, plan
tables, and vendor tools.



Cathy



From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of
[login to unmask email]
Sent: Wednesday, January 12, 2011 7:34 AM
To: [login to unmask email]
Subject: [DB2-L] SMS for DB2 Infrastructure



We are considering converting our DB2 Z/os V8 infrastructure
datasets to be SMS managed - this includes 18 test/systest subsystems
and 12 production subsystems - across 10 lpars. This is in preparation
for DB2 V10 (We know that it is not necessary to convert before V10 but
wanted to rid ourselves of managing the private volumes that we have
today).

In various IBM manuals we have seen that 3 storage groups are
recommended: 1 for the catalog and directory, 1 for the BSDS and active
logs and a third for DB2 application data. Our DASD group is trying to
convince us that separate SMS storage pools are unnecessary and we
should put the catalog, directory, BSDS and logs into the same SMS pool
as the application databases. Their contention is that with todays
technology (DS8000 model 8700) our non-SMS volumes (used today for
infrastructure) are just virtual volumes stripped across very large
physical drives so that in reality our infrastructure datasets are today
currently mixed in with everything anyway and trying to separate them
into separate SMS pools is unnecessary. We do have separate DB2
application database pools for production and test with different
migration strategies and ACS routines will be enhanced to further
differentiate migration strategies for archive logs etc.

Our questions:
1.What are other shops doing and what might have you done
differently now that you're using SMS?
2. If we have no intention of ever using BACKUP/RESTORE SYSTEM
functionality, is there any reason (recovery, performance or future
capabilities) that would prevent us from using the same SMS pools for
both DB2 infrastructure and DB2 application datasets?

I monitor the list with a condensed version once a day so if you
ask me any questions, I can't respond quickly.

Thanks for your thoughts.

ITG Enterprise Infrastructure
DB2 for Z/os Infrastructure
Voice: 570 585 3147
Email: [login to unmask email]

The information contained in this message may be CONFIDENTIAL
and is for the intended addressee only. Any unauthorized use,
dissemination of the information, or copying of this message is
prohibited. If you are not the intended addressee, please notify the
sender immediately and delete this message.



________________________________

Independent, not-for-profit, User Run - the IDUG difference!
< http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
If you are not already an IDUG member, please register here.
< http://www.idug.org/register >


________________________________

Introducing IBM(r) DB2(r) 10 for z/OS
< http://www-01.ibm.com/software/data/db2/zos/db2-10/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
If you are not already an IDUG member, please register here.
< http://www.idug.org/register >





Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

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

[login to unmask email]

Re: SMS for DB2 Infrastructure
(in response to John Amsden)
Hi Lyozwiak,

In our shop, we have even more than 10 SMS SGs for the most
important/largest DS group, yes it is a little bit too many,
but I agree 3 as you mentioned is the bottom line.
Today, based on the advanced disk tech, performance is not
the biggest concern any more, it is high availability and
manageability. Think why you need multiple DBs for tablespaces
and indexes? DB is just a logical object, you can put almost
everything into only one DB, but I believe no one did that.
The reason is for manageability, by DB we can group different
objects, issue deifferent commands, give different definitions,
in a word, operate it as a single one object, separated by
others. So does SMS. By multiple SGs, the storage admin can
group different datasets by their characteristics, such as
stripping or not, HSM migrate or not, FlashCopy enabling or
not, strictly high availability or not, etc.
So, multiple SGs does NOT always make your system more complicated,
and make your storage more work to do, sometimes it is easier to
manage and of higher productivity than all-in-one. The key point
is to find the trade-off/balance, depends on your environment.






[login to unmask email]
·¢¼þÈË: IDUG DB2-L <[login to unmask email]>
2011-01-12 23:33
Çë´ð¸´ ¸ø
IDUG DB2-L <[login to unmask email]>


ÊÕ¼þÈË
[login to unmask email]
³­ËÍ

Ö÷Ìâ
[DB2-L] SMS for DB2 Infrastructure






We are considering converting our DB2 Z/os V8 infrastructure datasets to
be SMS managed ¨C this includes 18 test/systest subsystems and 12
production subsystems ¨C across 10 lpars. This is in preparation for DB2
V10 (We know that it is not necessary to convert before V10 but wanted to
rid ourselves of managing the private volumes that we have today).

In various IBM manuals we have seen that 3 storage groups are recommended:
1 for the catalog and directory, 1 for the BSDS and active logs and a
third for DB2 application data. Our DASD group is trying to convince us
that separate SMS storage pools are unnecessary and we should put the
catalog, directory, BSDS and logs into the same SMS pool as the
application databases. Their contention is that with todays technology
(DS8000 model 8700) our non-SMS volumes (used today for infrastructure)
are just virtual volumes stripped across very large physical drives so
that in reality our infrastructure datasets are today currently mixed in
with everything anyway and trying to separate them into separate SMS pools
is unnecessary. We do have separate DB2 application database pools for
production and test with different migration strategies and ACS routines
will be enhanced to further differentiate migration strategies for archive
logs etc.

Our questions:
1.What are other shops doing and what might have you done differently now
that you're using SMS?
2. If we have no intention of ever using BACKUP/RESTORE SYSTEM
functionality, is there any reason (recovery, performance or future
capabilities) that would prevent us from using the same SMS pools for both
DB2 infrastructure and DB2 application datasets?

I monitor the list with a condensed version once a day so if you ask me
any questions, I can¡¯t respond quickly.

Thanks for your thoughts.

ITG Enterprise Infrastructure
DB2 for Z/os Infrastructure
Voice: 570 585 3147
Email: [login to unmask email]
The information contained in this message may be CONFIDENTIAL and is for
the intended addressee only. Any unauthorized use, dissemination of the
information, or copying of this message is prohibited. If you are not the
intended addressee, please notify the sender immediately and delete this
message.




The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
are not already an IDUG member, please register here.


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

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