Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RMAN Catalog Configuration
If you can think of any more configurations, or 'PROs and CONs' - let me
know.
option 1
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.
Thanks In Advance
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.
option 2
PROS
CONS
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.
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.
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
PROS
CONS
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.
????? I think I am missing something here - I can not think why you would
want to do this (see 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
CONS
Keeping the catalogs on independent hardware prevents a single point of
failure. RMAN West can backup RMAN East and visa-versa.
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-LReceived on Thu Mar 07 2002 - 10:03:28 CST
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).