Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RMAN Catalog Configuration
Now thats assuming Oracle's migration utility works :-) I always prefer exp/imp for upgrades, much cleaner. But will have to trust Oracle's migration utility for the 1TB db upgrade from 8.1.7 to 9i.
Gene
>>> rgramolini_at_tax.state.vt.us 03/12/02 07:58AM >>>
If I moved one database to a higher version I would upgrade my rman catalog
database and version at the same time. Since rman is backward compatible it
would be the easiest way.
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
Sent: Thursday, March 07, 2002 1:48 PM
Thanks for the summary. I prefer option 3. One advantage I see is upgrade migrations of databases. For example:
Db upgrades are easier when products are not co-mingled. I never mix Oracle products into the same base, home even though some supposedly work together like forms, oas, etc.
Just IMHO,
Gene
>>> phowe_at_Illuminet.com 03/07/02 11:03AM >>>
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.
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.
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).
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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Pat Howe INET: phowe_at_Illuminet.com 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: ListGuru_at_fatcity.com (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: Gene Sais INET: Gsais_at_co.palm-beach.fl.us 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: ListGuru_at_fatcity.com (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: rgramolini_at_tax.state.vt.us 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: ListGuru_at_fatcity.com (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: Gene Sais INET: Gsais_at_co.palm-beach.fl.us 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: ListGuru_at_fatcity.com (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).Received on Tue Mar 12 2002 - 09:33:28 CST