Re: Distibuted Databases

From: Jim Mclaughlin <mclaughl_at_ocdis01.tinker.af.mil>
Date: 1996/12/10
Message-ID: <32ADCABE.5B45_at_ocdis01.tinker.af.mil>#1/1


Rip,

You left out one facit of Oracle's symmetric replication and that is the N-Way master configuration. It uses deferred transaction queues to replicate transactions and pushes these to all other master sites via asynchronous propogation. One advantage with the N-Way master configuration is less complexity in the initial configuration as you will generally have only one schedule execution job per repgroup and associated master site. Additionally, I have not seen problems in N-Way master replication since 7.1.6; I have seen significant problems with updateable snapshots.

Jim McLaughlin

Rip McManus wrote:
>
> Yes. Database and network capacity are constraining factors, of course.
> Oracle (best with 7.2 or later) offers a number of critical distributed
> databasing tools which the vast majority of your distributed design will
> utilize. Check your favorite Oracle reference for syntax.
>
> First is the database link, which allows you to reference objects in remote
> databases and is central to most distributed database techniques. If you
> create a database link called simts from db1 to db2, you can then access
> objects in db2 from db1 by appending _at_simts to the object name. Note that
> operations involving objects in both databases will not be as efficient as
> they would be in either of them individually for a number of reasons.
>
> Second is the snapshot, an automatic asynchronous copy defined by
> relatively simple DDL. It has several update and refresh options, but the
> purpose is to keep a relatively current copy of a remote table in another
> database over a database link. Great for distributing copies of relatively
> static data. It recovers automatically from network and hardware failures,
> so it's a lot better way to do this than hand-crafting the code. But
> updates are only allowed on the master table in the master database. The
> copy is stored in a physical table (SNAP$_tablename) and a view built
> automatically with the name by which you intend to access it (typically
> tablename as in the master database). Indexes can be created, but are
> created on the SNAP$ table, of course, not the view.
>
> Third is symmetric replication, which is similar to snapshotting but allows
> updates on the remote table. So far, in my experience, this works better
> on paper than in real life. But, like snapshotting, it's relatively easy
> to set up and offers the same recovery features. Watch out for volume and
> complexity.
>
> Then there's two-phase commit. Depending on how distributed and reliable
> your WAN is, this may not be a great approach. All involved databases must
> successfully commit or all are rolled back. Any little anomaly in the
> network can wreak serious havoc on the transaction - it's synchronous and
> can't afford to be as resilient as the asynchronous techniques. But it's
> easy and may well be appropriate for your application. There's no special
> way to invoke this. Oracle does it automatically when your uncommitted
> transactions involve both local and remote database updates. But if you
> need serious synchronous transaction processing, you should probably
> consider a real client-server TP monitor like Tuxedo.
>
> Ripperm_at_aol.com
>
> Sim Thiam Soon <simts_at_swiftech.com.sg> wrote in article
> <32A8D8BA.3AA7_at_swiftech.com.sg>...
> > Hello
> >
> > Is it possible to use SQL*Net to implement Distributed database
> > application over a wide area network based on client server
> > architecture?
> >
> > What are the issues that must be observed when designed such an
> > application? Is there any methodology to follow to avoid the numerous
> > pitfalls?
> >
> > Can anyone help? Your comments and advice are appreciated
> >
Received on Tue Dec 10 1996 - 00:00:00 CET

Original text of this message