jang@forit.uit.no (Jan Grav) (06/05/90)
Two weeks ago I had the following note in comp.databases:
**Subject: References on Distributed Databases WANTED !
**I wonder if any of you have some information about commercially
**available Distributed Database Systems ( = name of product ) ?
**If you have some additional information about the system's
**fragmentation/replication/updating/... facilities or references
**for this information, this will also be of interest.
Here are the reponses :
-----------------------
-----------------------
From: Robert Claeson <prc@erbe.se>
Date: Tue, 29 May 90 08:35:21 -0200
Ingres/Star and Oracle*Star are two distributed database systems (I'm
sure there are more).
Ingres/Net, Oracle*Net, Informix-Net and Sybase are some
client-server networked database systems.
-----------------------------------------------------------------------------
From: "Bruce E. Golightly" <bg0l+@andrew.cmu.edu>
Date: Tue, 29 May 90 09:28:27 -0400 (EDT)
You should look at Ingres. They introduced the first production quality
distributed data base. Since they also use a server architecture (sp?),
and run on a variety of platforms, it has great potential for almost
any application.
There are, of course, problems. We've had some locking and concurrancy
problems that we were unable to resolve. Part of this is due to the
distributed nature of what we were attempting. This does not rule out
the possibility of a bug or bugs compounding a design problem.
As with any leading edge product, there are some real issues. We've had
permit and protection problems at times. Two-phase commit isn't in the
version we're using at present. There are issues around the use of Ingres
in a broader Unix based network related to authentication that we're very
concerned about.
#############################################################################
!
Bruce E. Golightly ! bg0l@andrew.cmu.edu (BeeGeeZeroEl)
Chief of Data Base Development ! (412)268-8560
Telecommunications Group !
Carnegie Mellon University ! UCC 117, 4910 Forbes Ave.
! Pittsburgh PA 15213-3890
Vice President, Western Penna IUA !
#############################################################################
------------------------------------------------------------------------------
From hokey@plus5.com Tue May 29 07:05:15 1990
Date: Mon, 28 May 90 23:56:26 -0500
If I understood your question a bit better I could probably tell you what
you wanted to know as far as our Mumps implementation under Unix goes.
Hokey
-----------------------------------------------------------------------------
Organization: NCR Corporation, Rancho Bernardo
From: benl%adt.sandiego.ncr.com@RELAY.CS.NET
Date: Mon, 28 May 90 12:38:50 -0400 (at ncrlnk.Dayton.NCR.COM)
For heterogenous distributed database capabilities, i.e. to connect
applications to more than one type (or vendor) of database, check
out Oracle SQL*Star and Ingres Star. Functionality and performance
wise, I prefer Ingres' products.
If you are happy utilizing only one vendor, Sybase is technically a
superior product in terms of performance and functionality. E.g.
it provides an efficient Remote Procedure Call (RPC) capability.
>If you have some additional information about the system's
>fragmentation/replication/updating/... facilities or references
>for this information, this will also be of interest.
>From first-hand experience, I'll warn you to scrutinize vendor's
claims, ad nauseam. Oracle, for example has long claimed update
capability to DB2, but they failed to mention that SQL*Forms --
their flag-ship (yech) application generator) could only be used
in the read mode! Another example is that both Oracle and Ingres
provide RPC-like capabilities, but this works only against their
RDBMS, not through their Gateways.
DATAPRO Research Notes has a relatively good overview of all the
big commercially avaiable products.
Qualifying Comments:
I'm passing this on as a result of first-hand research, and from an
evaluation done by our RDBMS group here at NCR. I've also only hit
the big commercial products, and have not considered products from
Europe.
--
Benoit.Lheureux@sandiego.NCR.COM ####################################
Application Dev Tools, Dept 4775 # Opinions are my own, not NCR's #
16550 West Bernardo Drive # Farewell Micro C Magazine #
San Diego, CA 92127 619/485-3578 ####################################
-------------------------------------------------------------------------
From: endrizzi@SCTC.COM (Michael Endrizzi )
Date: Mon, 28 May 90 08:30:55 CDT
Book by Papdimitriaou(??) called The Theory of Database
Concurrency Control put out by Compuer Science Press in
1986.
Dreez
-------------------------------------------------------------------------
From: John Hanley <jhanley@us.oracle.com>
Date: Wed, 30 May 90 03:02:09 PDT
Organization: Oracle Corporation
Oracle's product currently addresses pieces of the Distributed Database
problem, with database links (location indepence via SQL*Net) and
Table Replication (increased availability and fault tolerance via
special logging and consistency checks, with automatic update progation).
--JH
----------------------------------------------------------------------------
From: cognos!nigelc (Nigel Campbell)
Date: Thu, 31 May 90 19:35:15 EDT
Organization: Cognos Inc., Ottawa, Canada
Starbase from Cognos which is based on Interbase from Interbase Corp
is a distributed database running on
Vax-Vms/Ultrix,Sun,Apollo,Aviion,Hp-Ux,Hp-Xl,Os/2 and Xenix
can have multiple databases per machine
uses a client-server model
supports tcp/ip and dec-net
passes database requests/messages in a form called Blr which
minimises the overhead on the network
supports Digitals DSRI thus any DSRI compliant software could
access the database
uses the distributed lock manager on the Vax
supports the two-phased commit protocol with a dba tool for
determining what to do with transactions that did not complete
during the two-phased commit
The database does not support fragmentation or replication currently
which as you are probably aware does not come cheaply . However using
our 4.gl. Powerhouse it is possible to describe multiple databases
to the Powerhouse dictionary thus supporting location transparency as
well as joining of relations from multiple databases . Version 3 of
the database supports a database event which allows programs to trap
until the event is signalled by the database trigger code : this would
allow you to create a daemon whos function it was to replicate certain data .
A simple example of this feature was to create a code management system/mail
system which watched for events to do with your user name etc .
Limits
# relations per database - none
# databases concurrently accessible - none
# indexes per database - none
# indexes per relation - 64
row size - 65,000 bytes
tuples per relation - none
field size excluding Blobs - 32,000 bytes
columns per relation - 16,000
characters per column - 32,000
Index key - 255 bytes
Blob size - none
#concurrent accessors - none
Note that full record compression and index compression is applied in the
database .
regards . Nigel
--
Nigel Campbell Voice: (613) 783-6828 P.O. Box 9707
Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr.
uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc Ottawa, Ontario
CANADA K1G 3Z4
-----------------------------------------------------------------------------
From: Dean Swan <dean@sun.soe.clarkson.edu>
Date: Fri, 1 Jun 90 10:38:20 EDT
My company is implementing a fairly large expenditure tracking systems
for the New York State Office of Mental Retardation and Developmental
Disabilities. We have been developing the system in Clipper (a dBase
dialect compiler), more because the project was started four years
ago as a single user, stand-alone system on one machine, and it's
rather expensive to throw out 30k lines of existing, working code.
Clipper has *no* built in distributed database support. One of the
problems that we faced is that a Developmental Center in th OMRDD system
has multiple community offices that are remote sites, supervising and
supporting community residences. They spend money, and their expenditures
need to be tracked. It is unreasonable to have a centralized staff
do all the administrative work for the community offices, so we implemented
a distributed system, where each community office has their own PC, on
which they can perform all functions that the main office can.
Since a wide area network was not feasible (one of out sites covers a
seven county region and has 3 community offices) we implemented a "sneaker-
net", where data is checked in and out and transported by floppy disk.
This system has presented a number of problems. First and most substantial
is the problem of synchronization and signalling. We modeled the system
loosely on a client-server model. The machine at the main office is
considered the home-base, and each community office is considered a
satallite system. The problems arrise when, for example, a satellite
transmits a batch of information to the host. It needs to know what has
already been sent, and successfully receved by the homebase so that it
can avoid redundacy, and only transmit new information. Similar problems
exist in transmitting information from the home base to the satellites.
This has been described by some texts as a "Red Army, Blue Army problem".
The analogy is that if you have the Blue army in the center of a valley,
and the Red army divided in half on either side of the Blue army, your
plan is to attack simultaneously. If you are Red army, part 1 and you send
a messenger to Red army, part 2 saying "Attack at dawn". You have no way
of knowing whether the messenger reached the other side. Part 2 could send
a messenger back to you, but then they have no way of knowing that you
actually received the message.
So, the problem is basically that the transmitter never knows if their
message has been received. This problem can come up when dealing with
'sockets' under BSD implementations of Unix, as well. One way to ensure
that data is not duplicated, and that message are always confirmed is
to enforce a restriction that a given transmitter may not transmit again
until it has received an acknowledgement from the receiver. Unfortunately,
this was neither possible nor practical for our expenditure tracking system.
Our solution was that a transmitter always re-transmits information for which
it has not received a confirmation, and a reciever will incorporate from the
incoming information, only new information that is not already present in
it's local database. Whenever a transmitter sends more information, it
includes a confirmation log of information that it has already recieved.
Eventually, the system stabilizes itself, and only new information is
transmitted, and only the most recent confirmations are carried. There
is usually only one frame (i.e. the previous transmission, plus the new
transmision's information) of overlap due to the exchange of confirmations
being asynchronous.
Another reasonable example of this effect at work is the concept of a
"working set" in a demand paged virtual memory system. References to this
can be found in DEC's VAX series documentation, various texts on operating
systems (especially BSD implementations of UNIX, and references to DEC's VMS)
and books on computer architectures (i.e. Tannenbaum's "Sturcture Computer
Organization").
I don't know if this is what you're looking for, but it is at least our
one real-world experience to draw on. The most impressive implementation
of a distributed database that I can think of is the inter-net name
server system.
Feel free to e-mail if you wish to discuss any further.
-Dean Swan
dean@sun.soe.clarkson.edu