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

Home -> Community -> Usenet -> c.d.o.server -> Re: Replication - how hard is it really? (Updatable snapshots..)

Re: Replication - how hard is it really? (Updatable snapshots..)

From: Kevin A Lewis <KevinALewis_at_Hotmail.com>
Date: Mon, 14 Jun 1999 09:36:59 +0100
Message-ID: <i5393.1699$Tf6.10740@newreader.ukcore.bt.net>


I mostly endorse what Jonathan has said - although I would add that you can consider Asyncronous if you are able to control the application enough to avoid Data Ownership conflicts. That is each site / snapshot is responsible for a subset of the data thus avoiding update conflicts.

Other than that insert and update conflicts are one thing (i.e. possible to work out a scheme for), however delete conflicts are something else again. The best way to deal with these is to change all active deleting into updates with 'mark for delete' which is actioned later in background after update conflicts have been resolved.

One other aspect which is difficult is knowing what is happening during replication. Oracle has a 'replication black box' which is very difficult to see inside during replication.

In conclusion,

Replication is a reasonable tool if understood (i.e. do the course and experiment before committing to it!!).

Regards and good hunting
--
Kevin A Lewis (BOCM PAULS LTD - Animal Feed Manufacturer - Ipswich England)

                        <KevinALewis_at_HotMail.com>

The views expressed herein by the author of this document are not necessarily those of BOCM PAULS Ltd. Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote in message news:929342622.2103.0.nnrp-07.9e984b29_at_news.demon.co.uk...
>
> The actual preparation of definitions, installation and
> general mechanical activity is a bit long-winded and
> fiddly but not too painful, and things shouldn't get
> too difficult with only two nodes, BUT ...
>
> The main problem is covering all the angles of dealing
> with 'conflict resolution' - defining rules for ways in which
> the system should behave when the same record is
> updated differently at both ends of the system.
>
> Oracle offers several conflict resolution rules to help,
> but you still have to decide which one applies when,
> and whether you want to invent some of your own;
> then you still end up with a lot of hassle when something
> goes wrong and you have to tidy up.
>
> Personally I always advise fairly strongly against using an
> asynchronously replicated system on the basis of the
> high probability of unanticipated situations occurring and
> the cost of resolving them when they do.
>
> --
>
> Jonathan Lewis
> Yet another Oracle-related web site: www.jlcomp.demon.co.uk
>
> mdlcpgs_at_alpha.gns.cri.nz.nospam wrote in message
> <7k1qac$j2p$1_at_newshost.comnet.co.nz>...
> >We are comtemplating setting up replication between 2 Oracle Workgroup
> >servers. One is the master, but the other needs updatable copies of some
> >of the tables stored at the master. On any day, both the master and the
> >remote snapshot could be independently updated. We would hope to
> synchronize
> >with a new snapshot process every night.
> >
> >While Oracle says that the server supports multiple updatable snapshots,
we
> >have been given some warnings by a third party (that might have some axes
> to
> >grind) that replication is actually fraught with problems and we should
> avoid
> >at all possible. What are peoples experience of this kind of replication?
> >What can go wrong? Does it need constant maintenence or is it just major
> >pain to set up? Your experiences please!
>
>
>
Received on Mon Jun 14 1999 - 03:36:59 CDT

Original text of this message

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