Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Recovery in a Replicated environment

RE: Recovery in a Replicated environment

From: <rajeshm_at_crt.com>
Date: Thu, 29 Jun 2000 08:37:57 -0500
Message-Id: <10543.110775@fatcity.com>


Just curious how large are the databases, and what methods you use to reconcile data across regions. Is the reconciliation a brute force method i.e. record by record comparisons, or it is more advanced technique.

thanks.

> -----Original Message-----
> From: kit.cunningham [SMTP:kit.cunningham_at_4f.co.nz]
> Sent: Thursday, June 29, 2000 3:38 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Recovery in a Replicated environment
>
> I support a site using 4 irix systems running oracle 7.3.3 , each is a
> master.
>
> Each region manages its own data which is replicated to other regions. The
> recordid defines the region as well as the record number.
>
> We deem any region to "own" its data. Weekend checks compare the
> replicated tables and any records not in sync are written (after checking
> for why) from the "owning" database to the other systems.
>
> Thus any extended downtime can be recovered using manual methods far
> quicker than waiting for replication catch up.
>
>
> Kit
>
> "A. Bardeen" wrote:
>
> > Tina,
> >
> > If you find any, I'd love to see them too!
> >
> > Here are some issues, off the top of my head and in no
> > particular order, that need to be considered for
> > recovery in an n-way replication environment (you have
> > more flexibility since you're essentially doing
> > one-way replication for failover):
> >
> > * SET UP CONFLICT RESOLUTION!!!!!!
> > In the case of point-in-time recovery (PITR) this
> > is absolutely critical, unless you want to add the
> > stress and hassle of having to manually resolve
> > conflicts onto what is quite likely already a
> > stressful situation!
> > Even in the case of 1-way replication, you'd be
> > surprised how easy it is for someone to let users into
> > the wrong site or for a batch job or script to be run
> > on the wrong site.
> >
> > * How will you handle PITR? If you perform it only
> > one site, your replicated objects will be out of sync.
> > Do you plan on resynching the tables after the
> > recovery? If so, what is the interaction between the
> > non-replicated tables (which have been recovered to an
> > older point-in-time) with the replicated tables (which
> > have been resynched with the other site(s))?
> >
> > * Did I mention conflict resolution?! Many people
> > avoid conflict resolution because it forces you to
> > really analyze the business flow and needs of the
> > application. IMHO it's a case of "pay me now or go
> > bankrupt later!"
> >
> > * How long can you afford an outage. One thing a lot
> > of people never consider is whether their replication
> > environment can ever "catch up" from an extended
> > outage at one site. The tx's will continue to pile up
> > at the other site(s), but once the down site comes
> > back up how long will it take to push that backlog.
> > This is a very critical issue on Oracle7 since the
> > only option is a serial push (O8 allows parallel
> > pushing along with additional architectural changes
> > which dramatically increase performance for
> > replication).
> >
> > * If complete recovery and allowing the backed up
> > tx's to be pushed is not an option, how do you plan to
> > get your sites in sync again? Can you afford the
> > downtime needed for offline instantiation? Remember
> > that almost all administrative tasks require
> > suspending replication for the group being suspended
> > (all groups on O7) and that while a group is
> > quiescing/quiesced no DML operations are allowed on
> > the replicated objects.
> >
> > Again, I cannot emphasize enough the importance of a
> > robust conflict resolution scheme. In many cases it
> > can mean the difference between keeping and losing
> > your job!
> >
> > Additions, corrections, and comments are, of course,
> > welcome.
> >
> > HTH,
> >
> > -- Anita
> >
> > --- Tina Ridgley <tlridgley_at_yahoo.com> wrote:
> > > Hi all.
> > >
> > > We are using multi-master replication using Oracle
> > > 8.1.6 running on Solaris 2.6. Although we are set
> > > up
> > > for multi-master replication, there will only be
> > > transaction activity at one site unless the primary
> > > site is lost, in which case we'll be switching to
> > > the
> > > secondary site.
> > >
> > > Does anyone have any experience performing recovery
> > > in
> > > this type of environment or know of any papers which
> > > outline what steps should be taken for performing
> > > recovery in a replicated environment using different
> > > recovery scenarios.
> > >
> > > I would appreciate any help I can get in this area
> > > as
> > > I have been having trouble finding any sources which
> > > address this with any level of detail.
> > >
> > > TIA,
> > >
> > > Tina
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get Yahoo! Mail - Free email you can access from
> > > anywhere!
> > > http://mail.yahoo.com/
> > > --
> > > Author: Tina Ridgley
> > > INET: tlridgley_at_yahoo.com
> > >
> > > Fat City Network Services -- (858) 538-5051 FAX:
> > > (858) 538-5051
> > > San Diego, California -- Public Internet
> > > access / Mailing Lists
> > >
> > --------------------------------------------------------------------
> > > 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).
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get Yahoo! Mail - Free email you can access from anywhere!
> > http://mail.yahoo.com/
> > --
> > Author: A. Bardeen
> > INET: abardeen1_at_yahoo.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > 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).
>
> -
>
> --
> Author: kit.cunningham
> INET: kit.cunningham_at_4f.co.nz
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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
Received on Thu Jun 29 2000 - 08:37:57 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US