Re: RMAN Catalog Configuration

One other thought is that RMAN doesn't back up oracle passwd files, init.ora file, oracle home files, etc. Also, RMAN does not back up redo logs.

>>> rgramolini_at_tax.state.vt.us 03/07/02 01:03PM >>>
I will put some comments inline:

HTH,
Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> 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 : 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).

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