[DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
Thank you very much for the valuable pieces of information! Here the points I've noted from your posts, in order to help others that may search for the same topic. The original question: I'm looking for some DB2 specific recommendations regarding User Catalogs, specially if there are any rules of thumb as a start point for defining the infrastructure for DB2 (like each member has its own catalog or something like that). Here the answers: - Frequently ICF catalogs are shared by many users / applications. It is unusual for a DB2 install today to include the allocation of a new user catalog. - Software, DB2 objects, and backups (Copies, logs etc) should not share the same HLQ - Make sure the storage management team know about the numbers and volitility of each type of dataset use - Sometimes it can be a good thing for the aliases (or vcatnames) used in multiple DB2 subsystems to be in separate ICF usercats. Then each subsystem can be granted update access only to the ICF usercat that has the aliases for it. - You're less likely to have an outage putting different components of a single DB2 sub-system into different ICF catalogues. Do your job as a DBA and let the Storage Admins do theirs. - Chapter 4.1.7 from redbook Data Sharing in a Nutshell (http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf) has some recommendations about User Catalogs. - Page 140 from redbook DB2 9 for z/OS and Storage Management (http://www.redbooks.ibm.com/redbooks/pdfs/sg247823.pdf) has similar recommendations. - If you intend to use SYSTEM BACKUP there are special recommendations regarding what objects should be put in each user catalog. - One should caution against a profusion of UCATs; it can lead to all sorts of recriminations when doing business continuity testing (Disaster recovery.) Suggestion: 4 UCATs; testing, production, pre-production testing and DB2. - In a small DB2 shop , one user catalog can support more subsystems ( PROD,TEST,DEVL) . Isolation of production is also a best practice. Depending on the number of archives logs that you produce and keep cataloged, they will consume space , size the catalog appropriately to avoid extents. - DB2 treats the whole group in a data sharing system as a logical entity, so different user catalogs for data sharing members won't work. And here the source: DB2-L Avram Friedman, Debora Gresham, Ted MacNEIL, Cathy Taddei, Cuneyt Goksu, Marcel Harleman IBM-Main Rick Fochtman, Ed Finnell, Kevin Clark, Wayne Driscoll -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
One exception to that would be if you intend to use system backup and system restore. Each subsystem needs two dedicated catalogs, BSDS, LOGS and ARCHLOGS in one, and all other stuff in another (at least that was the guidance given to us). Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
Why? --Original Message-- From: Paul Peplinski Sender: IBM Mainframe Discussion List To: IBM Mainframe Discussion List ReplyTo: IBM Mainframe Discussion List Subject: Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices Sent: 11 Nov 2011 17:26 One exception to that would be if you intend to use system backup and system restore. Each subsystem needs two dedicated catalogs, BSDS, LOGS and ARCHLOGS in one, and all other stuff in another (at least that was the guidance given to us). Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
Hi, I'm looking for some DB2 specific recommendations regarding User Catalogs, specially if there are any rules of thumb as a start point for defining the infrastructure for DB2 (like each member has its own catalog or something like that). I've searched the forum and asked daddy google, but didn't get smarter. The guys from DB2-L recommended me to post this to this list (IBM-Main). If some of you guys could share one or two links I would be very grateful! Thank you in advance! Rodney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
I don't have any DB2 specific advice regarding user catalogs, but when you ask about each member having its own catalog, if you mean member in the sense of DB2 data sharing, that really won't work, since DB2 treats the whole group as a logical entity. Now if you are referring to individual subsystems, I would recommend that you have at least one user catalog per DB2 subsystem or DSG, or at a minimum that you don't define the aliases for development and production in the same user catalog. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Rodney Krick r...@aformatik.de To: IBM-MAIN@bama.ua.edu Date: 11/10/2011 12:56 PM Subject: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi, I'm looking for some DB2 specific recommendations regarding User Catalogs, specially if there are any rules of thumb as a start point for defining the infrastructure for DB2 (like each member has its own catalog or something like that). I've searched the forum and asked daddy google, but didn't get smarter. The guys from DB2-L recommended me to post this to this list (IBM-Main). If some of you guys could share one or two links I would be very grateful! Thank you in advance! Rodney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
A few suggestion: We are a small DB2 shop , so one user catalog supports 3 subsystems ( PROD,TEST,DEVL) . Isolation of production is also a best practice. Depending on the number of archives logs that you produce and keep cataloged, they will consume space , size the catalog appropriately to avoid extents. Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Rodney Krick Sent: Thursday, November 10, 2011 1:43 PM To: IBM-MAIN@bama.ua.edu Subject: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices Hi, I'm looking for some DB2 specific recommendations regarding User Catalogs, specially if there are any rules of thumb as a start point for defining the infrastructure for DB2 (like each member has its own catalog or something like that). I've searched the forum and asked daddy google, but didn't get smarter. The guys from DB2-L recommended me to post this to this list (IBM-Main). If some of you guys could share one or two links I would be very grateful! Thank you in advance! Rodney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail message and any attachments transmitted with it are confidential and are intended solely for the use of its authorized recipient(s). If you are not an intended or authorized recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the information contained in this e-mail is prohibited. If you have received this message in error or are not authorized to receive it, please immediately notify the sender and delete the original message and all copies of it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
Part of it is nomenclature. DB/2 catalog vs MVS catalog. I put each DB/2 catalog in a separate UCAT. It's all part of the installation process for DB/2. Also specify SYSVOLs or SMS managed for tables and indices and matching SSI. Still want to buggy whip whomever picked DSN as DB/2 hlq! In a message dated 11/10/2011 1:24:26 P.M. Central Standard Time, wdri...@us.ibm.com writes: Now if you are referring to individual subsystems, I would recommend that you have at least one user catalog per DB2 subsystem or DSG, or at a minimum that you don't define the aliases for development and production in the same user catalog. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [DB2 z/OS] USER CATALOG - Rules of Thumb and best practices
---snip--- I don't have any DB2 specific advice regarding user catalogs, but when you ask about each member having its own catalog, if you mean member in the sense of DB2 data sharing, that really won't work, since DB2 treats the whole group as a logical entity. Now if you are referring to individual subsystems, I would recommend that you have at least one user catalog per DB2 subsystem or DSG, or at a minimum that you don't define the aliases for development and production in the same user catalog. --unsnip- I partly agree with Wayne. DB2 tables should have their own UCAT, separate from all other processing. I must caution against a profusion of UCATs; it can lead to all sorts of recriminations when doing business continuity testing (Disaster recovery.) I've always advocated 4 UCATs; testing, production, pre-production testing and DB2. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
