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

On 2/28/07, Jared Still <jkstill_at_gmail.com> wrote:
>
> 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. :)
>

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

--
http://www.freelists.org/webpage/oracle-l