Re: decision to use or not use an rman catalog?
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: "Jared Still" <jkstill@xxxxxxxxx>
- Date: Wed, 28 Feb 2007 19:38:29 +0000
On 2/28/07, Jared Still <jkstill@xxxxxxxxx> wrote:
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. :)
er, yes it is. oops
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.
of course parallelism is part of the rman configuration :)
configure channel device type disk to parallelism 4 format '/my location';
....
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.
Now that is a much more appropriate idea. kicks self.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
