Re: [oracle-l] rman catalog considerations

In this ³mutual supporting² configuration,you don¹t need additional
instances just to house the ³recovery catalog² database?  Your idea to house
them inside the ³business² instances is quite viable, as the RMAN ³recovery
catalog² is a very low-usage, low-traffic database application.
-----

May I ask a quick question:  why do you need to have a "recovery catalog"
database at all?

Running RMAN in "nocatalog" mode has exactly the same functionality as
running it with a "recovery catalog" database tacked on.  Reasons for using
a ³recovery catalog² database instead of NOCATALOG:

* storing information for periods of time longer than
CONTROLFILE_RECORD_KEEP_TIME
> * retaining information about READ ONLY tablespaces archived for months or
> years
* storing information across RESETLOGS
> * to allow recovery across RESETLOGS
* centralizing RMAN information from two or more ³target² databases
> * redundant backup of information stored in the controlfile

NOCATALOG isn¹t as risky as one might think.  It is easy and very natural to
be super-paranoid about controlfile backups ? flying NOCATALOG airlines just
gives another reason.  I¹ve always taken controlfile backups redundantly
during backups (one copy to disk as well as tape), and 9i¹s CONFIGURE
CONTROLFILE AUTOBACKUP just makes it easier.

I think most people assume that a ³recovery catalog² is required or even a
strongly recommended part of RMAN.  In reality, it is just an option that is
available for very specific reasons.  And, like many such options, it comes
at a cost in extra complexity:

* now there is another database to manage and backup
* upgrades from one version of RDBMS to another requires upgrade of the
corresponding ³recovery catalog² repository

If you don¹t intend to store recovery information for very long (i.e. Less
than 30 days), then you should really consider NOCATALOG.

Just my $0.02  (let the stone-throwing begin)...



on 1/23/04 2:33 PM, Daniel Hanks at hanksdc@xxxxxxxxxxxxx wrote:

> I'm in the process of revamping my backup procedures, and had some ideas I
> wanted to filter through the wisdom/experience of the list.
> 
> In my current setup, I have two main database machines, let's call them M1,
> and M2. 
> 
> - On M1, I have 2 instances, one 'business' instance, and 1 instance which
> serves as the recovery catalog for M2 (total of 2 instances).
> 
> - On M2 I have 2 'business' instances, and 1 instance which serves as the
> recovery catalog for M1 (total of 3 instances).
> 
> So essentially M1 hosts the recovery catalog for the databases on M2, and
> likewise M2 hosts the recovery catalog for the database on M1.
> 
> My question is, would it be prudent/beneficial to put the recovery catalogs
> into their own schemas in the 'business' instances, instead of maintaining
> them in their own instances?
> 
> Some benefits I see in doing this:
> 
> - That would make 2 less instances I have to concern myself with.
> - I now have (slightly) more memory/resources to allocate to the 'business'
> instances.
> - Backups of the recovery catalogs are now handled by the regular backups of
> the 'business' instances.
> 
> Some drawbacks to doing this:
> 
> - The recovery catalog is now 'coupled' to the business instance. If the
> business instance is down for an extended period of time (which 'should never
> happen'
> :-) then I'd be 'unable' to make rman backups of the other machine at least
> with the catalog.
> - Are there other drawbacks?
> 
> Thanks for your thoughts and suggestions,
> 
> -- Dan
> ========================================================================
>  Daniel Hanks - Systems/Database Administrator
>  About Inc., Web Services Division
> ========================================================================
> 


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: