Re: Distibuted Databases

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 Sun Dec 08 1996 - 00:00:00 CET