| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RMAN Catalog Configuration
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).
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).
Content-Type: text/plain; name="ReadMe.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit
The previous attachment was filtered out by the ListGuru mailing software at fatcity.com because binary attachments are not appropriate for mailing lists. If you want a copy of the attachment which was removed, contact the sender directly and ask for it to be sent to you by private E-mail.
This warning is inserted into all messages containing binary attachments which have been removed by ListGuru. If you have questions about this message, contact Postmaster_at_fatcity.com for clarification.
------_=_NextPart_001_01C1C75E.431E5880--
--
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).
 |
 |