Re: decision to use or not use an rman catalog?
- From: "Jared Still" <jkstill@xxxxxxxxx>
- To: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- Date: Wed, 28 Feb 2007 10:25:31 -0800
On 2/28/07, Niall Litchfield <niall.litchfield@xxxxxxxxx> 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
Other related posts:
