Oracle-L: RMAN Catalog Configuration

From: Pat Howe <phowe_at_Illuminet.com>
Date: Thu, 07 Mar 2002 08:03:28 -0800
Message-ID: <F001.00421FAF.20020307080328@fatcity.com>

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).

Patrick J. Howe
Oracle DBA
Illuminet Inc. (Carrier Division of Verisign) 4501 Intelco Loop SE
Olympia, WA 98507
Email : phowe_at_illuminet.com

-- 
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).

Received on Thu Mar 07 2002 - 10:03:28 CST