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).
Received on Mon Apr 07 2003 - 12:08:41 CDT
