I will put some comments inline: HTH, Ruth ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, March 07, 2002 11:03 AM
> I asked the LIST to respond to the PROs and CONs of different RMAN catalog > configuration options - Below is the summary of the discussion. > By getting a good picture of the different configuration options and what > their PRO's and CON's are - I will be able to choose the best setup for my > situation. > > If you can think of any more configurations, or 'PROs and CONs' - let me > know. > Thanks In Advance > > > option 1 > Create one RMAN database with one RMAN catalog for all the databases that > you are backing up. > IE; If you had two databases "PROD and DEV" then create one RMAN database > with one RMAN Catalog in one RMAN tablespace to manage all database recovery > info. > > PROS > Simple. > One set of scripts to maintain. > > CONS > When using SQL to query the RMAN catalog you will have to isolate the > database (join db key). > You will need to manually backup (script-backup) the RMAN database. > This really isn't a con. You can join the rc_database file with any query which used dbid to get the name of the database. > > option 2 > Create one RMAN database with one RMAN catalog per database that you are > backing up. > IE: If you had two databases "PROD and DEV" then setup one RMAN database > with an RMAN-PROD catalog and an RMAN-DEV catalog in the same RMAN > tablespace to manage each database's recovery info. > > PROS > When using SQL to query the RMAN catalog you do not have to isolate the > database (join dbkey). > Easier to maintain if you are dropping a database - Just drop the RMAN > schema owner. > This configuration adds a level of security by always matching the TARGET > you are on to the RMAN repository you are signing on to. > IE; If you were on TARGET PROD then you would have to signon to the > RMAN-PROD schema owner. > > CONS > Multiple RMAN catalogs will consume more physical space (their own set of > tables) on the RMAN > database. > You will need to maintain scripts in each RMAN catalog. > You will need to manually backup (script-backup) the RMAN database. I do a cold backup of my rman database once a week. Not really a need for many catalogs. > > > option 3 > Create an RMAN database for each version of database that you are backing > up. > IE: If you had to maintain two 8.1.7 databases and three 9.1 databases then > setup a RMAN817 database and a RMAN910 database (same box) to maintain the > two different versions of Oracle databases. > > PROS > ????? I think I am missing something here - I can not think why you would > want to do this (see CONS). > > CONS > This is not technically necessary. Lower levels of RMAN work with higher > levels of the RMAN catalog. > You will need to manually backup (script-backup) the RMAN database. > > > option 4 > Split up your RMAN catalogs by physical location. > IE: If you maintained a west coast set of databases and an east cost set of > databases then setup a RMAN-WEST database and an RMAN-EAST database > (different RMAN boxes in two physically different locals). > I have 3 boxes, one catalog. I just clone the scripts too...very easy. > PROS > Keeping the catalogs on independent hardware prevents a single point of > failure. RMAN West can backup RMAN East and visa-versa. > > CONS > Costly (2 boxes). You really only need a separate disk for the backups, not a whole separate box. And disk is cheap these days. > > _________________________ > Patrick J. Howe > Oracle DBA > Illuminet Inc. (Carrier Division of Verisign) > 4501 Intelco Loop SE > Olympia, WA 98507 > Email : [EMAIL PROTECTED] > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Pat Howe > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ruth Gramolini INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
