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

before I came here I was on large projects and they used hardware for the backups. They were done with BCV copies and rman was not used.

how common is that? Is that a better solution than rman? I would think it would get fairly expensive.
-------------- Original message --------------
From: "Niall Litchfield" <niall.litchfield_at_gmail.com> 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_at_gmail.com> 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_at_oneneck.com> 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
--

http://www.freelists.org/webpage/oracle-l Received on Wed Feb 28 2007 - 12:11:56 CST