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

Kevin and Jonathan make some very good points (are you guys related at all?). Having been the instructor for the replication class, and seen a lot of students through it, here's my viewpoint.

Replication in 7.3.4 and upwards (the only supported versions now) is a very robust product. The main problem I have seen with it has been people not understanding what it should be used for. For example, I had a student come to a class running on 7.2, and he wanted to use replication on a database that was handling 15 million transactions a day. Row level replication wasn't designed to handle that level of throughput. I've had other clients who set up 8 way multi-master replication with NO conflict resolution. Guess what the DBA's did all day? They manually resolved the conflicts, of course.

As with so many things in the database, use the product for what it's designed for. Don't try and force it into something else. Don't attempt to use something as advanced as replication without getting the training, and while you're doing it, talk to the instructor about the type of conflict resolution you want to set up. Pick the instructor's brains, they've done it lots of times before.

One small nitpick with a point of Kevin's. Replication isn't really a black box. If you want to drill into it, you can see all the packages and procedures at the API level. As with so many other things in this industry, though, there is a drive (and rightly so) towards ease of use, and that's where Replication Manager comes in. You CAN manage the environment completely through that, or you can get your hands dirty at the API level. The choice is yours.

HTH. Pete

Kevin A Lewis wrote:

> 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!
> >
> >
> >

--

Regards

Pete

Received on Mon Jun 14 1999 - 11:33:20 CDT