DB2 and ICF Catalogs

Irwin Deutsch

DB2 and ICF Catalogs
Hi,

We're a new DB2 shop on DB2 for z/OS v9. Currently we have one ICF catalog
for each DB2 subsystem, i.e. one for prod, one for test, etc.

Management is thinking of changing this to one for DB2 objects and another
one for logs (and BSDS') for recovery reasons, I guess. Just wondering
what the Pros and Cons would be for this and any user experience dealing
with implementation issues. Also does anyone know of any literature which
deals with this subject?

Thanks for any ideas!


Regards,

Irwin Deutsch
Princess Cruises


______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ted MacNEIL

Re: DB2 and ICF Catalogs
(in response to Irwin Deutsch)
>Management is thinking of changing this to one for DB2 objects and another one  for logs (and BSDS') for recovery reasons, I guess.
>Just wondering what the Pros and Cons would be for this and any user experience dealing with implementation issues.
>Also does anyone know of any literature which deals with this subject?

I don't know of any specific literature, but oi have 30+ years experience as a storage/performance/capacity analyst.
Why proliferate your catalogues?
Their just an index to your datasets, and, especially for online, they're only used at locate/create time.

Catalogues require management/backup/restore/recovery.
Why add more complication to an already complicated environment?
Talk with your storage people, but why is management giving you the solution?
They should be giving you the problem; technicians provide solutions.

Different aliases for different DB2's, yes!
Different catalogues? I wouldn't recommend it!

-
Too busy driving to stop for gas!

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: DB2 and ICF Catalogs
(in response to Philip Sevetson)
Irwin,

One _catalog_ for each setup, not just aliases? I'm fuzzy on catalogs,
haven't worked with them for a couple of years, but that sounds it won't
help them recover from a catalog failure. If the DB2 objects can't be
restored, it won't help you a lot to have DB2 subsystem logfiles and
BSDS.



You might want to have the first and second copies of executables (make
a backup copy), ZPARM modules (make a backup copy), active and archive
logfiles, catalog (DSNDB01) and directory (DSNDB06) spaces, and BSDS on
separate catalogs, though. BY WHICH I MEAN the first copy of everything
listed above, all together in one catalong, and one catalog for the
second copy of everything. Then if you make one catalog for all the the
DB2 application data objects, which you can afford to lose if you have
backups of everything... then one catalog for the local primary copies,
one for the local backup copies... that should give you enough
redundancy to come up after any single-point failure and most two-point
failures.



N.B. it doesn't matter where you put the DSNDB07 tablespaces, just bring
along the AMS filedef statements for them.



--Phil Sevetson



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Tuesday, January 20, 2009 2:48 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 and ICF Catalogs




Hi,

We're a new DB2 shop on DB2 for z/OS v9. Currently we have one ICF
catalog for each DB2 subsystem, i.e. one for prod, one for test, etc.

Management is thinking of changing this to one for DB2 objects and
another one for logs (and BSDS') for recovery reasons, I guess. Just
wondering what the Pros and Cons would be for this and any user
experience dealing with implementation issues. Also does anyone know of
any literature which deals with this subject?

Thanks for any ideas!


Regards,

Irwin Deutsch
Princess Cruises



________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
< http://idug.org/lsAU >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



=========
Confidentiality Notice: This e-mail communication, and any attachments, contains confidential and privileged information for the exclusive use of the recipient(s) named above. If you are not an intended recipient, or the employee or agent responsible to deliver it to an intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and delete this communication from your computer. Thank you.

Any opinions, expressed or implied, presented are solely those of the author and do not necessarily represent the opinions of the agency or the City.
=========



______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: DB2 and ICF Catalogs
(in response to Ted MacNEIL)
Ted, wouldn't it be better for DR to have multiple catalogs for the first and second copies of the BSDS/logfiles/what-have-you, so that losing one catalog doesn't wreck your recovery? Or can catalogs be rebuilt from recovered DASD volumes?

--Phil

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Ted MacNEIL
Sent: Tuesday, January 20, 2009 3:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs

>Management is thinking of changing this to one for DB2 objects and another one for logs (and BSDS') for recovery reasons, I guess.
>Just wondering what the Pros and Cons would be for this and any user experience dealing with implementation issues.
>Also does anyone know of any literature which deals with this subject?

I don't know of any specific literature, but oi have 30+ years experience as a storage/performance/capacity analyst.
Why proliferate your catalogues?
Their just an index to your datasets, and, especially for online, they're only used at locate/create time.

Catalogues require management/backup/restore/recovery.
Why add more complication to an already complicated environment?
Talk with your storage people, but why is management giving you the solution?
They should be giving you the problem; technicians provide solutions.

Different aliases for different DB2's, yes!
Different catalogues? I wouldn't recommend it!

-
Too busy driving to stop for gas!

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html


=========
Confidentiality Notice: This e-mail communication, and any attachments, contains confidential and privileged information for the exclusive use of the recipient(s) named above. If you are not an intended recipient, or the employee or agent responsible to deliver it to an intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and delete this communication from your computer. Thank you.

Any opinions, expressed or implied, presented are solely those of the author and do not necessarily represent the opinions of the agency or the City.
=========

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ted MacNEIL

Re: DB2 and ICF Catalogs
(in response to Philip Sevetson)
>Ted, wouldn't it be better for DR to have multiple catalogs for the first and second copies of the BSDS/logfiles/what-have-you, so that losing one catalog doesn't wreck your recovery? Or can catalogs be rebuilt from recovered DASD volumes?

1. Catalogue management is complex, so why add to it?
2. It's no different than than DB2 doing multiple joins to produce production data. What happens if one of the members of the join is lost.
3. Catalogues are pretty robust.
4. Yes, they can be rebuilt. They can also be backed up. It does require an investment.
5. Having muliple catalogues for each piece of a DB2, is like having multiple table spaces for each column in a DB2 object. IE: Index, field1; Index; field2; ... Index; fieldN. Would you do that in your design? A catalogue, while weak compared to DB2, is still a data-structure.

-
Too busy driving to stop for gas!

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Lizette Koehler

Re: DB2 and ICF Catalogs
(in response to Ted MacNEIL)
body{font-family: Geneva,Arial,Helvetica,sans-serif;font-size:9pt;background-color: #ffffff;color: black;}

Your backup and recovery process should probably be considered in this question.

With BACKUP in DB2 I have heard that a separate Catalog for the DB2 SYSTEM data sets (catalogs logs etc...) and another Catalog for the DB2 Application datasets (tables, tablespace etc...) for that DB2 Subsystem is a nice way to go.  And you may want to place your catalogs in the same DASD Pool as the DB2 Subsystem.  So if you had a catalog in a dasd pool outside of your DB2 backup setup, then it is possible to corrupt the db2 tables, tablespaces, catalogs because the catalog is out of time with the actual vsam data sets.

I am sure others have more input.

Lizette




 



Hi,

We're a new DB2 shop on DB2 for z/OS v9. Currently we have one ICF catalog for each DB2 subsystem, i.e. one for prod, one for test, etc.

Management is thinking of changing this to one for DB2 objects and another one  for logs (and BSDS') for recovery reasons, I guess. Just wondering what the Pros and Cons would be for this and any user experience dealing with implementation issues. Also does anyone know of any literature which deals with this subject?

Thanks for any ideas!


Regards,


IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia

IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register here.

Ted MacNEIL

Re: DB2 and ICF Catalogs
(in response to Lizette Koehler)
>Your backup and recovery process should probably be considered in this question.
With BACKUP in DB2 I have heard that a separate Catalog for the DB2 SYSTEM data sets (catalogs logs etc...) and another Catalog for the DB2 Application datasets (tables, tablespace etc...) for that DB2 Subsystem is a nice way to go.

This is not your grandfather's MVS.
All a BCS (basic catalgue structure) record has is an index record with the cluster/lds name and a pointer to the volume serial number.
The VSAM information is stored in the VVDS.
If your volume is intact, you can re-create the catalogue information, either manually or with a utility.

>And you may want to place your catalogs in the same DASD Pool as the DB2 Subsystem.  So if you had a catalog in a dasd pool outside of your DB2 backup setup, then it is possible to corrupt the db2 tables, tablespaces, catalogs because the catalog is out of time with the actual vsam data sets.

Only if the dataset has been moved to another volume (rare).
All the descriptors are in the VVDS and the VTOCIX.

This is ICF we're discussing.
Not that DB2 can/will use the old native VSAM.

Splitting datasets around catalogues just introduces management/backup/restore/recovery issues.

If you lose a catalogue, re-create it, and re-catalogue the datasets.


-
Too busy driving to stop for gas!

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Irwin Deutsch

Re: DB2 and ICF Catalogs
(in response to Ted MacNEIL)
Thanks! I appreciate the responses.

I found out some more info. Our vendor (EMC) has recommended this
separation of object data from log data as well as separate catalogs, so
that in case of full volume restores we don't need to restore the logs
too. It sounds like a pretty good idea, but I haven't seen it in the
several other DB2 shops I've worked in.


Thanks,

Irwin

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: DB2 and ICF Catalogs
(in response to Irwin Deutsch)
If you're going to do it that way, you need either to have a system
quiesce so as to flush all buffers and close all units of work.... Or
you need to be _certain_ that you have captured all the logs which might
be involved in rolling back any unit of work that was inflight when the
DB2 system was last checkpointed before the EMC cutover. Then be
absolutely sure that all your logs are captured at a point in time equal
to or before any of your data objects.



Yes, it's complicated - sorry about the second sentence but I don't
think it can be meaningfully simplified.



--Phil Sevetson



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Tuesday, January 20, 2009 6:34 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Thanks! I appreciate the responses.

I found out some more info. Our vendor (EMC) has recommended this
separation of object data from log data as well as separate catalogs, so
that in case of full volume restores we don't need to restore the logs
too. It sounds like a pretty good idea, but I haven't seen it in the
several other DB2 shops I've worked in.


Thanks,

Irwin

________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
< http://idug.org/lsAU >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Raymond Bell

Re: DB2 and ICF Catalogs
(in response to Philip Sevetson)
Hmmm... coupla thoughts here, some (all?) of which might not be
interesting/relevant.



I must confess to reading 'separate ICF catalogs' as 'separate dataset
high-level qualifiers' which isn't the same thing. Whether or not you
have separate ICF catalogs for 'User' data and 'DB2 system' data may or
may not be important (I'd go have a chat to your resident Storage
Administrator for that discussion) but I've personally been a fan of one
HLQ for all objects in a DB2 subsystem. Makes it easier to find all the
datasets that belong to that subsystem. Typically multiple HLQs is done
to make dataset chargeback easier; not a good reason, just a common one.



If the idea is not to pick up any DB2 system objects in any required
full-volume restores then the ICF catalog they're part of doesn't
matter, as that has nothing to do with physical dataset placement. If
it's just separation of user and system DB2 objects you're after, ACS
routines can take care of that. And of course, if you lose a DASD
volume and, ahem, have a certain Solution from a certain vendor, you can
quickly build a recovery job to recover all objects on that volume,
either by having it use the VVDS or by looking on the actual device.



DR is a whole other discussion. Phil's right; it's complicated.



Hope that's of some interest.



Cheers,





Raymond





From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: 21 January 2009 00:23
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs



If you're going to do it that way, you need either to have a system
quiesce so as to flush all buffers and close all units of work.... Or
you need to be _certain_ that you have captured all the logs which might
be involved in rolling back any unit of work that was inflight when the
DB2 system was last checkpointed before the EMC cutover. Then be
absolutely sure that all your logs are captured at a point in time equal
to or before any of your data objects.



Yes, it's complicated - sorry about the second sentence but I don't
think it can be meaningfully simplified.



--Phil Sevetson



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Tuesday, January 20, 2009 6:34 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Thanks! I appreciate the responses.

I found out some more info. Our vendor (EMC) has recommended this
separation of object data from log data as well as separate catalogs, so
that in case of full volume restores we don't need to restore the logs
too. It sounds like a pretty good idea, but I haven't seen it in the
several other DB2 shops I've worked in.


Thanks,

Irwin

________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
< http://idug.org/lsAU >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ted MacNEIL

Re: DB2 and ICF Catalogs
(in response to Raymond Bell)
>I must confess to reading ‘separate ICF catalogs’ as ‘separate dataset high-level qualifiers’ which isn’t the same thing.

No, but putting pieces of one DB2 (or anything) into separate ICF catalogues, does force separate qualifiers, since you cannot use the same one in two different catalogues.
Unless, you go to multi-level aliases, which is its own management headache.

I think people are worrying about an nit.
All a catalogue does is tell you which disk a given dataset is on.
All the other descriptors for the dataset are on the volume on which it resides, in the VTOC, the VTOCIX, and the VVDS.
If I lose the catalogue, I can re-create it and rebuild it.
If I lose the catalogue I cannot access (or create new, or delete) the associated datasets until the rebuild, unless they are already open.
If I have multiple catalogues, and one fails, the effect is the same.

-
Too busy driving to stop for gas!


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Cathy Taddei

Re: DB2 and ICF Catalogs
(in response to Ted MacNEIL)
One reason to put things in separate ICF catalogs is to reduce single points of failure. If you use separate HLQ's for the member-specific datasets of each data sharing member, and put them in separate catalogs, you will have a slightly higher chance of keeping your DB2 data sharing group alive in case of a catalog problem, due either to software bug or disk failure. This is an extreme measure, and I would not advocate it to any shop that has not already gone to great lengths to ensure duplication of everything possible. If you don't already have redundant data centers with full replication and a dedicated storage team that will have already done this for you (which would mean you wouldn't even be asking the question), then you should not proliferate ICF catalogs.

Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Ted MacNEIL
Sent: Wednesday, January 21, 2009 3:01 AM
To: [login to unmask email]
Subject: Re: DB2 and ICF Catalogs

>I must confess to reading 'separate ICF catalogs' as 'separate dataset high-level qualifiers' which isn't the same thing.

No, but putting pieces of one DB2 (or anything) into separate ICF catalogues, does force separate qualifiers, since you cannot use the same one in two different catalogues.
Unless, you go to multi-level aliases, which is its own management headache.

I think people are worrying about an nit.
All a catalogue does is tell you which disk a given dataset is on.
All the other descriptors for the dataset are on the volume on which it resides, in the VTOC, the VTOCIX, and the VVDS.
If I lose the catalogue, I can re-create it and rebuild it.
If I lose the catalogue I cannot access (or create new, or delete) the associated datasets until the rebuild, unless they are already open.
If I have multiple catalogues, and one fails, the effect is the same.

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

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.

=====


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Irwin Deutsch

Re: DB2 and ICF Catalogs
(in response to Cathy Taddei)
Raymond, it's not so much a separation into different volumes (and
catalogs) of system objects from application objects., but rather a
separation of all objects and the active logs. That's so we can still
recover to current time, in case we lose the data. Now we do have the
archive logs on tape so that mitigates that problem somewhat, of
recovering to current time.

To me it boils down to a question of should these objects (tablespaces and
active logs) be put on separate volumes and/or catalogs for volume
recovery. Management thinking here is that catalogs and their datasets
should be on their own packs, so restores will keep them in sync.
Management is going ahead with this with or without my support, as I'm the
new kid on the block (as Rodney says about getting no respect). My main
purpose is to see if there are any strong arguments against it or warnings
about it.

Phil, I'm not sure if I understand your point about flushing the buffers
with Quiesce. Is that right before the full volume backups? If so, it sure
makes sense! This brings up another issue about non-DB2 backups versus
image copies. After all Snaps are much quicker, but are probably more
difficult to use in at recovery time. If any one has any ideas there or
can point me to archived items I'd sure appreciate it.

Thanks all for your contribution here!


Irwin




______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ted MacNEIL

Re: DB2 and ICF Catalogs
(in response to Irwin Deutsch)
>One reason to put things in separate ICF catalogs is to reduce single points of failure. If you use separate HLQ's for the member-specific datasets of each data sharing member, and put them in separate catalogs, you will have a slightly higher chance of keeping your DB2 data sharing group alive in case of a catalog problem, due either to software bug or disk failure.

As I said, a NIT.
Catalogue falure after a dataset is opened affects NOTHING.

There are only three things in a BCS record.
The dataset name, the device type, and the volume serial number(s) of the device.

Everything else is described on the associated disk.
Back when everything VSAM was described in the catalogue, this was an issue.
But, DB2 never used this kind of catalogue.
Only ICF catalogues have ever been allowed for DB2 objects.

There are better things to do for recovery and restore of DB2 objects, than to introduce an extra set of complex procedure for little, or no gain, and a false sense of SECURITY.

For the record, I think that EMC is wrong in making the recommendation.
This is akin to over-normalisation of DB2 application data.

-
Too busy driving to stop for gas!


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: DB2 and ICF Catalogs
(in response to Ted MacNEIL)
Irwin,



I'm treading on thin ice, here - I worked on this stuff a while back but
the devil is definitely in the details.



I think you want a -STOP DB2 MODE(QUIESCE), or at the very least a SET
LOG SUSPEND, at just before the start of any SNAP, lasting until the
cutover is complete. Otherwise, you run the risk of updates to the
database that are not found on the log at recovery time.



For most shops these days, a -STOP isn't an option, so look into SET LOG
SUSPEND - it'll let you run your SNAP without any risk of update
anomalies. But if you've got the option of doing a -STOP, do so. It'll
flush the buffers, complete all units of work, set a system checkpoint,
and close your active logs. (It also does drains and windows, and
vacuums the carpet.)



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Wednesday, January 21, 2009 12:45 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Raymond, it's not so much a separation into different volumes (and
catalogs) of system objects from application objects., but rather a
separation of all objects and the active logs. That's so we can still
recover to current time, in case we lose the data. Now we do have the
archive logs on tape so that mitigates that problem somewhat, of
recovering to current time.

To me it boils down to a question of should these objects (tablespaces
and active logs) be put on separate volumes and/or catalogs for volume
recovery. Management thinking here is that catalogs and their datasets
should be on their own packs, so restores will keep them in sync.
Management is going ahead with this with or without my support, as I'm
the new kid on the block (as Rodney says about getting no respect). My
main purpose is to see if there are any strong arguments against it or
warnings about it.

Phil, I'm not sure if I understand your point about flushing the buffers
with Quiesce. Is that right before the full volume backups? If so, it
sure makes sense! This brings up another issue about non-DB2 backups
versus image copies. After all Snaps are much quicker, but are probably
more difficult to use in at recovery time. If any one has any ideas
there or can point me to archived items I'd sure appreciate it.

Thanks all for your contribution here!


Irwin




________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



=========
Confidentiality Notice: This e-mail communication, and any attachments, contains confidential and privileged information for the exclusive use of the recipient(s) named above. If you are not an intended recipient, or the employee or agent responsible to deliver it to an intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and delete this communication from your computer. Thank you.

Any opinions, expressed or implied, presented are solely those of the author and do not necessarily represent the opinions of the agency or the City.
=========




______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Irwin Deutsch

Re: DB2 and ICF Catalogs
(in response to Philip Sevetson)
Thanks, Phil. I've just been reminded of the log suspends and resumes,
which I've never used before.

Next question is what are the advantages/disadvantages of recovering from
snap copies versus image copies? I would think a disadvantage is the
difficulty in finding the correct snap copy, as it's not recorded in the
DB2 catalog.


Thanks again.

Irwin


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Philip Sevetson

Re: DB2 and ICF Catalogs
(in response to Irwin Deutsch)
Irwin,



You don't do a normal recovery from a snap copy. They're for DR only -
you restore the whole DASD suite, bring up DB2, and it rolls back all
inflight transactions, then you're open for business.



If you need to recover from a SNAP copy, the preferred solution (my
opinion, of course) is to have someone copy the needed dataset(s) from
the SNAP copy to a standard volume, RENAME the dataset underlying the
production object to get it out of the way, RENAME the
copied-to-a-standard-volume dataset to what DB2 is expecting for the
production object, UNLOAD the data you need, and reverse the naming so
that you have the current production object's current dataset in the
right place. Then you take the UNLOADed data and manipulate that (LOAD
REPLACE or whatever) to fix your business problem. It's a nasty long
risky way to solve the problem, and Image Copies are a much better
solution to most of your business needs.



Image copies are still necessary to cover the need to roll back from
major errors in the business process, fix broken REORGs, recover from
bad data, and the occasional erroneously-deleted file. (And for
disaster recovery at my current client, which doesn't rely on volume
copies, they're still important.)



--Phil



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Wednesday, January 21, 2009 3:33 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Thanks, Phil. I've just been reminded of the log suspends and resumes,
which I've never used before.

Next question is what are the advantages/disadvantages of recovering
from snap copies versus image copies? I would think a disadvantage is
the difficulty in finding the correct snap copy, as it's not recorded
in the DB2 catalog.


Thanks again.

Irwin

________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Raymond Bell

Re: DB2 and ICF Catalogs
(in response to Philip Sevetson)
Guys,



You can indeed do local recoveries from snap copies i.e. those copies
taken by whatever intelligent storage device (DS8300, RVA, Shark, SVA,
Symmetrix, etc) you have. If you have the right products they'll get
registered in Syscopy just like ordinary ICs - or somewhere
Syscopy-like, depending on which of the 4 types of snap you did. Irwin,
you know who you should talk to if you're interested. Sam A's your man.



For DR, I agree with Phil once more; a quiet point is required. Or
rather, a consistent point. Again, if you have the right products (now
who could I be thinking of...) you can get one without -STOpping DB2
(yikes) or even suspending the Log. And at the risk of annoying at
least one colleague of mine who dislikes this phrase; cool, huh?



If you've got snap-capable ISDs if would be a shame not to at least look
at snap copies for local recovery, especially for your larger objects.
Just my 1.44p' worth (the rate's slightly worse today).



Cheers,





Raymond



From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: 21 January 2009 21:23
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs



Irwin,



You don't do a normal recovery from a snap copy. They're for DR only -
you restore the whole DASD suite, bring up DB2, and it rolls back all
inflight transactions, then you're open for business.



If you need to recover from a SNAP copy, the preferred solution (my
opinion, of course) is to have someone copy the needed dataset(s) from
the SNAP copy to a standard volume, RENAME the dataset underlying the
production object to get it out of the way, RENAME the
copied-to-a-standard-volume dataset to what DB2 is expecting for the
production object, UNLOAD the data you need, and reverse the naming so
that you have the current production object's current dataset in the
right place. Then you take the UNLOADed data and manipulate that (LOAD
REPLACE or whatever) to fix your business problem. It's a nasty long
risky way to solve the problem, and Image Copies are a much better
solution to most of your business needs.



Image copies are still necessary to cover the need to roll back from
major errors in the business process, fix broken REORGs, recover from
bad data, and the occasional erroneously-deleted file. (And for
disaster recovery at my current client, which doesn't rely on volume
copies, they're still important.)



--Phil



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Wednesday, January 21, 2009 3:33 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Thanks, Phil. I've just been reminded of the log suspends and resumes,
which I've never used before.

Next question is what are the advantages/disadvantages of recovering
from snap copies versus image copies? I would think a disadvantage is
the difficulty in finding the correct snap copy, as it's not recorded
in the DB2 catalog.


Thanks again.

Irwin

________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Carol Broyles

Re: DB2 and ICF Catalogs
(in response to Raymond Bell)
Have any of you looked at BACKUP SYSTEM/RESTORE SYSTEM? It requires at
least three ICF catalogs per DB2 system; one for the logs and boot strap
datasets, one for the catalog and directory, and one for user data.
We're not actually using it yet, because we don't have HSM installed.
We are creating all new systems this way so we'll be set up correctly
when we do. We use FDR and we're trying to prod Innovation to give us
the same functionality.





Carol L. Broyles

Infrastructure Mgt. Consultant

Commercial Solutions

Office Phone: 937-495-4003

[login to unmask email]



Affiliated Computer Services Inc.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,

is for the sole use of the intended recipient(s) and may contain
confidential and

privileged information. Any unauthorized review, use, disclosure, or
distribution is

prohibited. If you are not the intended recipient, please contact the
sender by reply

e-mail and destroy all copies of the original message.



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Bell, Raymond
Sent: Thursday, January 22, 2009 4:23 AM
To: [login to unmask email]
Subject: Re: DB2 and ICF Catalogs



Guys,



You can indeed do local recoveries from snap copies i.e. those copies
taken by whatever intelligent storage device (DS8300, RVA, Shark, SVA,
Symmetrix, etc) you have. If you have the right products they'll get
registered in Syscopy just like ordinary ICs - or somewhere
Syscopy-like, depending on which of the 4 types of snap you did. Irwin,
you know who you should talk to if you're interested. Sam A's your man.



For DR, I agree with Phil once more; a quiet point is required. Or
rather, a consistent point. Again, if you have the right products (now
who could I be thinking of...) you can get one without -STOpping DB2
(yikes) or even suspending the Log. And at the risk of annoying at
least one colleague of mine who dislikes this phrase; cool, huh?



If you've got snap-capable ISDs if would be a shame not to at least look
at snap copies for local recovery, especially for your larger objects.
Just my 1.44p' worth (the rate's slightly worse today).



Cheers,





Raymond



From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Sevetson, Phil
Sent: 21 January 2009 21:23
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs



Irwin,



You don't do a normal recovery from a snap copy. They're for DR only -
you restore the whole DASD suite, bring up DB2, and it rolls back all
inflight transactions, then you're open for business.



If you need to recover from a SNAP copy, the preferred solution (my
opinion, of course) is to have someone copy the needed dataset(s) from
the SNAP copy to a standard volume, RENAME the dataset underlying the
production object to get it out of the way, RENAME the
copied-to-a-standard-volume dataset to what DB2 is expecting for the
production object, UNLOAD the data you need, and reverse the naming so
that you have the current production object's current dataset in the
right place. Then you take the UNLOADed data and manipulate that (LOAD
REPLACE or whatever) to fix your business problem. It's a nasty long
risky way to solve the problem, and Image Copies are a much better
solution to most of your business needs.



Image copies are still necessary to cover the need to roll back from
major errors in the business process, fix broken REORGs, recover from
bad data, and the occasional erroneously-deleted file. (And for
disaster recovery at my current client, which doesn't rely on volume
copies, they're still important.)



--Phil



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Irwin Deutsch
Sent: Wednesday, January 21, 2009 3:33 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and ICF Catalogs




Thanks, Phil. I've just been reminded of the log suspends and resumes,
which I've never used before.

Next question is what are the advantages/disadvantages of recovering
from snap copies versus image copies? I would think a disadvantage is
the difficulty in finding the correct snap copy, as it's not recorded
in the DB2 catalog.


Thanks again.

Irwin

________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >



________________________________

IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


________________________________

IDUG 2009 - Australasia * 18-20 March * Melbourne, Australia
< http://idug.org/lsAU >

IDUG.org < http://www.idug.org > was recently updated requiring members
to use a new password. You should have gotten an e-mail with the
temporary password assigned to your account. Please log in and update
your member profile. If you are not already an IDUG.org member, please
register here. < http://www.idug.org/component/juser/register.html >


______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Mark McCormack

DB2 and ICF Catalogs
(in response to Carol Broyles)
<< Next question is what are the advantages/disadvantages of recovering
from
snap copies versus image copies? >>

Irwin,

You are now moving the discussion into another area. It is possible to
use snap copies instead of image copies for local site recovery. We
have been doing it for years. It works well. This is too detailed to
cover everything in a short email, so this is high-level stuff only.

advantage: periodic backups are much faster
disadvantage: recovery is slower and requires more manual effort -
identify proper snap copy backup, then restore vsam data set(s), then
DB2 RECOVER LOGONLY utility

1. We use EMC hardware, so our snap copies involve EMC's BCV (business
continuity volume) split process. Backups are not recorded as image
copies in sysibm.syscopy.
2. It is necessary to run -SET LOG SUSPEND before snap copy and -SET
LOG RESUME after snap copy. In other words, it is essential to prevent
table changes during BCV splits. Otherwise there are potential data
integrity issues involving data sets in multiple extents on one or
multiple dasd volumes.
3. You must treat all snap copies like SHRLEVEL CHANGE image copies
(aka 'fuzzy' copies) unless DB2 is down when snap copies are made. It
is possible that most recent table changes are not yet written to dasd
but are still in the buffer pool. In other words, the snap copy may not
have all data, but log files will.
4. After restore of vsam data set(s) for a tablespace from snap copy,
it is necessary to run RECOVER LOGONLY to current or TORBA/TOLOGPOINT
to process any needed log data. Since we do not create our indices COPY
YES, we must then REBUILD INDEX(s).

We run image copy when we must, such as with REORG or LOAD LOG NO
(mostly inline copies). But the BCV split process provides our normal
daily backups.

My comments apply through DB2v8. BACKUP SYSTEM and RESTORE SYSTEM under
DB2v8 are designed for ERP software like SAP. We do not use them. We
have also not yet begun our DB2v9 adventure, so I do not know if changes
to the BACKUP SYSTEM process will cause us to change what we do.

Mark

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Irwin Deutsch

Re: DB2 and ICF Catalogs
(in response to Mark McCormack)
Carol,

EMC provides 'equivalent' support for BACKUP SYSTEM/RESTORE SYSTEM
without the need for HSM. We're having a conference call with them later
today to find out more. In DB2 V9 you can restore by tablespace, while in
V8 you can only do a whole system restore. We use FDR also to make
offline copies from the BCV splits.


HTH,

Irwin




______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Chris White

Re: DB2 and ICF Catalogs
(in response to Irwin Deutsch)
Re ICF catalog strategy for DB2...

I agree with Ted’s take on this. Here’s why… The notion there is safety in
getting away from a “single point of failure” is questionable for exactly the
same reason it uses to support its own premise. One might argue that
spreading objects for any single environment across multiple ICF catalogs
could increase that environment’s exposure to ICF failure (more catalogs
means more chances for one to fail).

I also think it is naïve to depend entirely on complicated software (i.e. storage-
centric products that promise “magic”) for recovering the most critical
company assets… data and information. So here’s how I tried to build things…

1. We use one ICF catalog per DB2 environment for system and data (including
all DB2 subsystems within a data sharing group). You may have as many
aliases you wish (or can keep track of) but they are all cataloged in the same
ICF usercat. We can very easily differentiate “system” objects
from “application” objects by the alias they use. A single catalog for each
environment makes it very easy to move a DB2 environment to a CPC(s) with a
different ICF environment.

2. Archive log copy1 can be handled by SMS. This allows us to take
advantage of all the neat features in HSM, virtual tape, SMS (and whatever
other abbreviations they have).

3. Archive log copy2 goes directly to tape, bypassing most of the storage bells
and whistles. The tape’s volser is recorded in DB2’s BSDS. If there is a
disaster and storage management has difficulty restoring some of their magical
virtual goodies, DB2 can still find what it needs by calling for the volume
(doesn’t even need ICF for that).

This strategy is flexible because it takes advantage of high-end storage
products if they are available, but it also provides a way for DBA’s and
SYSADMs to start working if the storage team is having trouble getting all their
tools working. It fits what someone else alluded to... the need to be able to
recover from various kinds and degrees of disaster.

Chris White
Ex-DB2 Sysprog
Caterpillar Inc.

Note - These are just my opinions, not my employer’s and blah, blah, blah…

===<snip>===>
On Wed, 21 Jan 2009 16:22:44 -0500, Sevetson, Phil
<[login to unmask email]> wrote:

>Irwin,
>
>
>
>You don't do a normal recovery from a snap copy. They're for DR only -
>you restore the whole DASD suite, bring up DB2, and it rolls back all
>inflight transactions, then you're open for business.
>
>
>
>If you need to recover from a SNAP copy, the preferred solution (my
>opinion, of course) is to have someone copy the needed dataset(s) from
>the SNAP copy to a standard volume, RENAME the dataset underlying the
>production object to get it out of the way, RENAME the
>copied-to-a-standard-volume dataset to what DB2 is expecting for the
>production object, UNLOAD the data you need, and reverse the naming so
>that you have the current production object's current dataset in the
>right place. Then you take the UNLOADed data and manipulate that (LOAD
>REPLACE or whatever) to fix your business problem. It's a nasty long
>risky way to solve the problem, and Image Copies are a much better
>solution to most of your business needs.
>
>
>
>Image copies are still necessary to cover the need to roll back from
>major errors in the business process, fix broken REORGs, recover from
>bad data, and the occasional erroneously-deleted file. (And for
>disaster recovery at my current client, which doesn't rely on volume
>copies, they're still important.)
>
>
>
>--Phil
>
>
>
>________________________________
>
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>Behalf Of Irwin Deutsch
>Sent: Wednesday, January 21, 2009 3:33 PM
>To: [login to unmask email]
>Subject: Re: [DB2-L] DB2 and ICF Catalogs
>
>
>
>
>Thanks, Phil. I've just been reminded of the log suspends and resumes,
>which I've never used before.
>
>Next question is what are the advantages/disadvantages of recovering
>from snap copies versus image copies? I would think a disadvantage is
>the difficulty in finding the correct snap copy, as it's not recorded
>in the DB2 catalog.
>
>
>Thanks again.
>
>Irwin
>
>________________________________
>
>IDUG 2009 - Europe * 5-9 October * Rome, Italy < http://idug.org/lseu >
>
>IDUG.org < http://www.idug.org > was recently updated requiring members
>to use a new password. You should have gotten an e-mail with the
>temporary password assigned to your account. Please log in and update
>your member profile. If you are not already an IDUG.org member, please
>register here. < http://www.idug.org/component/juser/register.html >
>
>
>
>_________________________________________________________________
_____
>
>* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
>_________________________________________________________________
_____
>
>
>
>IDUG.org was recently updated requiring members to use a new password.
You should have gotten an e-mail with the temporary password assigned to
your account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html
>

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html