Re: decision to use or not use an rman catalog?
- From: ryan_gaffuri@xxxxxxxxxxx
- To: niall.litchfield@xxxxxxxxx, jkstill@xxxxxxxxx
- Date: Wed, 28 Feb 2007 18:11:56 +0000
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:
