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

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: