Re: [oracle-l] rman catalog considerations
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 29 Jan 2004 21:04:22 -0700
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 //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
- » Re: [oracle-l] rman catalog considerations
