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@xxxxxxxxx> 
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: