Re: RMAN Catalog: 1 vs. many - Opinions

Metalink Note 73431.1 "RMAN Compatibility Matrix" documents many version nuances.
 From the "Oracle Backup and Recovery 101" book, a simple idea of using a separate
recovery catalog schema for each major oracle version (e.g. rman806, rman816, rman817,
rman901, rman920) avoids some compatibility issues and configuration steps.

RMAN backups can be done using controlfiles, then connecting and resyncing with
recovery catalog(s) (one at a time - primary then secondary).

Have Fun :)

DENNIS WILLIAMS wrote:

>Deepak
> I think your list looks good. As I recall, the RMAN catalog must be the
>same version as the databases it is backing (or newer). So one advantage of
>separate catalogs would be that you aren't forced to upgrade your entire
>RMAN process to a new version just because you upgraded one of your
>databases. Suppose, for example your system administrators say they would
>have to upgrade the operating system of the RMAN catalog platform, and they
>can't do that right away?
> When you say that many catalogs eliminates a single point of failure,
>perhaps you could elaborate. Do you mean you would have a single backup
>server that would host all the RMAN catalogs?
> I would repeat my suggestion that you consider a non-catalog RMAN system.
>In Oracle8i Oracle seemed to say you really should only consider using a
>catalog. In Oracle9i a lot of features that previously were available only
>if a catalog was used were made available to control file backups. There are
>a lot of people that are now asking whether they really need to bother with
>a catalog. I currently use a catalog for our production backups but I am
>seriously considering control file backups on future systems.
>
>Dennis Williams
>DBA, 40%OCP, 100% DBA
>Lifetouch, Inc.
>dwilliams_at_lifetouch.com
>
>
>-----Original Message-----
>Sent: Monday, April 07, 2003 12:09 PM
>To: Multiple recipients of list ORACLE-L
>
>
>I have put together advantages of both options (1 vs
>many). I am still not clear whether to have 1 catalog
>or several (for each database). Please add your
>comments to this list.
>
>1 catalog
>---------
>. Ease of upgrading Oracle version (just need to
>upgrade 1 catalog)
>. A common place to connect to when doing
>backup/restore
>. Can report on ALL databases' backups using 1 catalog
>
>Many catalogs
>-------------
>. Overcome potential locking problem if several
>backups take place at the same time
>. Overcome single point of failure
>. Easy to get rid of obsolete database(s) from catalog
>(just drop the catalog schema)
>
>
>
>
>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Chip
  INET: ocp-dba_at_earthlink.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).