Deepak
I think your list looks good. As I recall, the RMAN catalog must be the
same version as the databases it is backing (or newer). So one advantage of
separate catalogs would be that you aren't forced to upgrade your entire
RMAN process to a new version just because you upgraded one of your
databases. Suppose, for example your system administrators say they would
have to upgrade the operating system of the RMAN catalog platform, and they
can't do that right away?
When you say that many catalogs eliminates a single point of failure,
perhaps you could elaborate. Do you mean you would have a single backup
server that would host all the RMAN catalogs?
I would repeat my suggestion that you consider a non-catalog RMAN system.
In Oracle8i Oracle seemed to say you really should only consider using a
catalog. In Oracle9i a lot of features that previously were available only
if a catalog was used were made available to control file backups. There are
a lot of people that are now asking whether they really need to bother with
a catalog. I currently use a catalog for our production backups but I am
seriously considering control file backups on future systems.
Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Monday, April 07, 2003 12:09 PM
To: Multiple recipients of list ORACLE-L
I have put together advantages of both options (1 vs
many). I am still not clear whether to have 1 catalog
or several (for each database). Please add your
comments to this list.
1 catalog
. Ease of upgrading Oracle version (just need to
upgrade 1 catalog)
. A common place to connect to when doing
backup/restore
. Can report on ALL databases' backups using 1 catalog
Many catalogs
. Overcome potential locking problem if several
backups take place at the same time
. Overcome single point of failure
. Easy to get rid of obsolete database(s) from catalog
(just drop the catalog schema)
- Yechiel Adar <adar76_at_inter.net.il> wrote:
> RE: RMAN Catalog: 1 vs. many - OpinionsYou should
> also stagger the backup jobs due to the workload on
> the tape system. We had recently a failed backup
> that was diagnosed as overload on the tape system.
>
> Yechiel Adar
> Mehish
> ----- Original Message -----
> From: Paula_Stankus_at_doh.state.fl.us
> To: Multiple recipients of list ORACLE-L
> Sent: Sunday, April 06, 2003 10:48 PM
> Subject: RE: RMAN Catalog: 1 vs. many - Opinions
>
>
> Deepak
>
> -I think the backup and mirroring address the
> issues of single point of failure. Therefore, the I
> think the consensus was use as few as possible RMAN
> catalogs - the only issue being locking and
> contention (performance of the catalog itself).
>
> Oracle OCP DBA
>
>
>
> -----Original Message-----
> From: Deepak Sharma [mailto:sharmakdeep_at_yahoo.com]
>
> Sent: Sunday, April 06, 2003 4:19 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: RMAN Catalog: 1 vs. many - Opinions
>
>
>
> Thanks ALL.
>
> Although it's a good practice to have separate
> RMAN
> server, with a good backup, mirrored disks etc.
> But,
> coming to my original question: should I use 1
> catalog
> or multiple catalogs (I may not be using
> controlfile
> approach) to back up 200+ databases? The only
> arguement I have heard so far is to have multiple
> catalogs to overcome possible locking issues. I do
>
> feel that for ease of maintenace, have 1 (or few)
> catalog to back-up all databases. It does become a
>
> single point of failure, though, if someone screws
>
> with that catalog. On the other hand, tasks such
> as
> upgrading Oracle version of the catalog becomes
> easier.
>
> -- Deepak
>
> --- Gaja Krishna Vaidyanatha
> <oraperfman_at_yahoo.com>
> wrote:
> > Hello X$KG...;-),
> >
> > Great to hear from you. You bring up a valid
> point.
> > I
> > agree with your comment and there may have been
> a
> > bit
> > of miscommunication on my part. I did suggest a
> > "dedicated RMAN server" for the task, I should
> have
> > said "dedicated RMAN servers". Running all the
> > backup
> > jobs at the same time can cause the problem that
> you
> > have suggested. Staggering them is one option
> along
> > with the idea of creating multiple RMAN
> catalogs.
> > The
> > main point I was trying to bring across was the
> need
> > for a "logical backup" of the RMAN catalog, over
> and
> > above a file-level backup of that database.
> >
> >
> > --- K Gopalakrishnan <kaygopal_at_yahoo.com> wrote:
>
> > > Gaja:
> > >
> > > Having dedicated RMAN server is indeed a good
>
> > idea,
> > > but RMAN catalog is not designed for that much
>
> > (!!?)
> > > high concurrency. If you look at the commands
> > > (executed
> > > by the RMAN during backup) very closely, you
> will
> > > see
> > > lots of SELECT for UPDATE and this will cause
> a
> > big
> > > bottleneck in the backup process.
> > >
> > > It happened at one of our client place where
> they
> > > backup
> > > 200+ databases with a single RMAN catalog at
> 2-3
> > > hrs
> > > interval. The workaround suggested was
> > > a) Have more RMAN Catalogs
> > > b) Run the backup in different times.
> > >
> > > So again it 'all depends '
> > >
> > > Best Regards,
> > > K Gopalakrishnan
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > Krishna Vaidyanatha
> > > Sent: Friday, April 04, 2003 4:04 PM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > > Paul et al.,
> > >
> > > I agree with Paul's setup of a dedicated RMAN
> > > catalog
> > > server. It is not a bad idea to have the
> datafiles
> > > for
> > > this database on mirrored volumes. I also
> think a
> > > good
> > > practice related to "saving the catalog"
> against
> > > tape
> > > media errors is to do a full export on the
> RMAN
> > > Catalog DB and stash the export dumpfile away
> on a
> > > mirrored volume away from the datafiles.
> > >
> > > If this DB has nothing but the RMAN catalog,
> it
> > > should
> > > not be very large (let me know if this is
> > otherwise)
> > > and thus the full export will be a good method
> to
> > > have
> > > a "logical backup". One more thing to save the
>
> > skin
> > > on
> > > your back, at a time of need. When Murphy is
> > around
> > > I
> > > think the word "mercy" vanishes from the
> English
> > > dictionary.
> > >
> > >
> > > Cheers,
> > >
> > > Gaja
> > >
> > > --- Paula_Stankus_at_doh.state.fl.us wrote:
> > > > I have setup a server for just rman catalog
> > backed
> > > > up to tape with clones
> > > > offsite for DR. It makes it easier as
> scripts
> > are
> > > > parameterized to keep
> > > > aware of backup statuses = etc. Having this
> on
> > a
> > > > centralized management
> > > > server and can't believe this isn't just
> common
> > > > practice. Just make sure no
> > > > single point of failure.
> > > >
> > > > Oracle OCP DBA
> > > >
> > > >
> > > > -----Original Message-----
> > > > Sent: Friday, April 04, 2003 3:39 PM
> > > > To: Multiple recipients of list ORACLE-L
>
=== message truncated ===
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Deepak Sharma
INET: sharmakdeep_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Mon Apr 07 2003 - 14:55:59 CDT
