Re: decision to use or not use an rman catalog?
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: jkstill@xxxxxxxxx
- Date: Wed, 28 Feb 2007 16:01:33 +0000
I'd agree with the others Ryan - I don;t see a catalog being merited in your
situation.
To disagree a bit with Jared - oooh two OakTable members disagree, the shame
of it! <vbg>
I think that the (10g) rman catalog has 2 things going for it in a larger
environment - unfortunately one of those doesn't quite work - when compared
with a traditional shell script based solution.
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.
2. The scripts are physically written and edited multiple times. This leads
to typos.
I much prefer setting the redundancy policy, backup location and so on in
the RMAN environment and then scheduling a known good backup script. This is
easy with a catalog and global scripts - hence the 10g remark. it tends not
to work with multiple shell scripts. For what it's worth our scripts are
fairly simple - there's a full backup, a level 0 and level 1 backup, an
archive log backup and a rman maintenance script. all of these are pretty
much the obvious one liners.
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!.
Now certainly neither of those apply to Ryan's case, but I think they could
apply to quite a few people. As for rman requiring another database, we just
stick the catalog in the grid control database, but any dba controlled
database would do (say an r&d environment or a statspack repository). I do
see a new database as a high price to pay for the above, I don't see a new
schema as such a big deal.
cheers
Niall
On 2/27/07, Jared Still <jkstill@xxxxxxxxx> wrote:
Ditto. Being able to store scripts in the repository is not worth
having another database IMO.
On 2/27/07, Allen, Brandon < Brandon.Allen@xxxxxxxxxxx> wrote:
>
> I'd use rman w/o catalog unless you can come with a compelling reason
> not to. Reasons to use rman w/ catalog would be if you wanted to store rman
> scripts in the catalog database, or if you were concerned with keeping more
> history than can be kept in your controlfile. Turn on the controlfile
> autobackup option.
>
> Regards,
> Brandon
>
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.
>
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Other related posts:
