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
> > >
> > >
> > > Deepak
> > > You may also wish to consider not using
> > > catalog(s) -- control file
> > > backups. This might make it easier to add and
> > remove
> > > databases in your
> > > environment. I'm presuming most databases are on
> > > their own server.
> > > If you want to be able to run a single query
> > that
> > > will report any backup
> > > problems across all your databases, you will use
> a
> > > single catalog.
> > >
> > > Dennis Williams
> > > DBA, 40%OCP, 100% DBA
> > > Lifetouch, Inc.
> > > dwilliams_at_lifetouch.com
> > >
> > >
> > > -----Original Message-----
> > > Sent: Friday, April 04, 2003 2:09 PM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > >
> > > We are in the process of moving from traditional
> > hot
> > > backups to one using RMAN. Total databases are
> > > around
> > > 200+. Should we be using 1 or few RMAN catalogs,
> > or
> > > 1
> > > catalog per database?
> > >
> > > Thanks,
> > > Deepak
> > >
> > >
> __________________________________________________
> > > 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
> > >
> >
>
>
Oracle DBA,
Minneapolis, MN
USA
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: Yechiel Adar
INET: adar76_at_inter.net.il
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 - 02:48:36 CDT
