Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: decision to use or not use an rman catalog?

Re: decision to use or not use an rman catalog?

From: Jared Still <jkstill_at_gmail.com>
Date: Wed, 28 Feb 2007 10:25:31 -0800
Message-ID: <bf46380702281025i31d6d22fp9f3e68173cef43ef@mail.gmail.com>


On 2/28/07, Niall Litchfield <niall.litchfield_at_gmail.com> wrote:
>
> To disagree a bit with Jared - oooh two OakTable members disagree, the
> shame of it! <vbg>

The shame!

First consistency of scripts. I do like having one standard for backup
> scripts, that is flexible enough to work in every environment. I also like
> my backups to be policy driven. We have a bunch of scripts, hand written for
> each environment. This leads to two things.
>
> 1. Backups are taken in different ways depending upon who set up the
> environment. Incremental, or not incremental; compressed or not compressed;
> auto backup on or off and so on.

not to be too picky, but autoback on/off does not need to be scripted. that is part of RMAN config, part
of backup setup routines. :)

2. The scripts are physically written and edited multiple times. This leads
> to typos.

Re the 10g features: I have mostly 9i databases, so I haven't really explored what 10g has to offer.

As for script consistency, we have 2 environments, Windows and Linux. I have a std
script for each. I have found that writing a global script to be more complicated than I like,
as not all environments are the same. Some servers use a single channel, some 2, and some
use 3 channels.

Adding a channel to the script is easy, writing a global script to deal with that is not.

Second, reporting. I don't want 30 emails a day containing different formats
> of reports on backups for different environments. I want a single report
> that highlights failures. The rman catalog in principle makes this simple -
> unfortunately I've found that using the 10.2 catalog and 10.1 databases
> gives unreliable results!.

The reporting is definetely a nice feature. I have gone a different way with that however, and have
implemented some PL/SQL Tim Gorman wrote that makes it simple to test if a database is recoverable
to a point and time, and report on that. Much better than looking at backup reports.

The backup report data is there if needed, I just don't want to see if unless needed.

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Feb 28 2007 - 12:25:31 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US