desmond@godot.UUCP (01/16/86)
Can anybody refer me to a survey of database software for UNIX systems? Better yet, can anyone recommend a package for a fairly large application on a VAX 11-750?
pavlov@hscfvax.UUCP (840033@G.Pavlov) (01/20/86)
If the goal is to settle upon a common dbms that will be effective for a wide
range of applications (my assumption, since it sounds like a number of sites
are involved), then I personally do not believe that either Unify or Informix
is the "answer". Of current dbms's for Unix systems, I would choose Ingres or
Oracle.
- this is based on hands-on evaluations of 5 dbms's (including Unify, but not
Informix), discussions with managers at apx. 30 sites using one or more of
the dbms's mentioned above, and discussions on this net over the past 12
months.
by Ingres, I mean the "commercial version", distributed by Relational Technoo-
logy, Inc.
greg pavlov, fstrf, amherst, ny
mo@wgivax.UUCP (01/23/86)
Look into ORACLE and SIR. Both have problems (ORACLE did not support
4.2 as of July, 1985 and SIR did not support multiple users except
if everyone is interfacing through screens -- no simultaneous batch
or ad hoc queries -- as of August, 1985).
Informix and Unify just won't cut it for large applications, and Ingres
(commercial or not) has a lot of bugs in their UNIX version (the current
UNIX 4.2 port was not even able to complete the turorial outlined in the
manuals without severely crashing). Ingres also requires mods to the
kernel, which some (including myself) feel is a bad way to implement
locking.
These comments stem from an in depth evaluation of these software systems
in July, 1985, including on-hands with SIR, INGRES, and INFORMIX. ORACLE
did not have a version available for 4.2 at the time, and UNIFY was just
too limiting.
Our final decision was to keep what we had -- a Britton Lee Database Machine,
the only valid solution to large database applications (500+ Mb) in the UNIX
environment today (-: in my opinion, of course :-). We have since bought a
second IDM.
BTW: Britton Lee just announced a new "deskside" database machine for around
$40,000 with disk, making it competitive with software systems.
Some addresses you might find useful:
Britton Lee, Inc SIR, Inc ORACLE
14600 Winchester Blvd 5215 Old Orchard Rd
Los Gatos, CA 95030 Skokie, IL 60077 Menlo Park, CA
(408) 378-7000 (312) 470-9770 (415) 854-7350jmc@ptsfa.UUCP (Jerry Carlin) (01/27/86)
In article <131@wgivax.UUCP> mo@wgivax.UUCP writes: > ... Ingres also requires mods to the kernel... Actually, Ingres has a locking pseuodo device driver. I do not think that adding a "device" driver is equivalent to "mods to the kernel" since you are not changing kernel source code. -- voice= 415 823-2441 uucp={ihnp4,dual,qantel}!ptsfa!jmc
pavlov@hscfvax.UUCP (840033@G.Pavlov) (01/28/86)
>Re: Ingres very buggy on Unix machines:
I would talk to some current sites before I rejected Ingres on the basis of
that statement. We ran the same DBMS's (plus Unify and Mistress) and talked
to apx. 40-50 other sites. Our evaluation lead to the opposite conclusion;
we purchased RTI's Ingres. I do agree with the the general assessment of
Unify and Informix, however.
ed@mtxinu.UUCP (Ed Gould) (01/28/86)
>> ... Ingres also requires mods to the kernel... > >Actually, Ingres has a locking pseuodo device driver. I do not think that >adding a "device" driver is equivalent to "mods to the kernel" since you >are not changing kernel source code. There are several versions of Ingres. The current commercial version from RTI does not require kernel mods, although older versions did. The current mechanism just adds a driver. Research Ingres, running on 4.2/4.3BSD uses a user-level lock manager that communicates with the database software via a socket. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
mats@fortune.UUCP (Mats Wichmann) (01/31/86)
The version of Ingres I have seen depended on existing locking
routines if they were there (as they are in many microports),
but in this case you had to modify the process exit code (inside
the kernel, not the stub in libc) to make sure to leave things clean.
The other approach, of course, is the already mentioned
"device driver". Either way, this is not very nice.
Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!matsdbmt@brl-tgr.UUCP (02/06/86)
In article <509@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>> ... Ingres also requires mods to the kernel... >> >>Actually, Ingres has a locking pseuodo device driver. I do not think that >>adding a "device" driver is equivalent to "mods to the kernel" since you >>are not changing kernel source code. > >There are several versions of Ingres. The current commercial version >from RTI does not require kernel mods, although older versions did. >The current mechanism just adds a driver. Research Ingres, running >on 4.2/4.3BSD uses a user-level lock manager that communicates with >the database software via a socket. > We, at BRL have a lock daemon supplied by RTI. As far as I know, we are the only such installation. It was developed for us by RTI, at our insistence, as a prototype to aviod the kernel mod required by INGRES 2.0. We have been using it successfully since June 1985. I have been trying to persuade RTI to support it as an alternative; but they won't commit themselves. Maybe a little pressure from netland...
jackg@tektronix.UUCP (Jack Griffith) (02/11/86)
In article <2155@brl-tgr.ARPA>, dbmt@brl-tgr.ARPA (Data Base Management Team ) writes: > In article <509@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: > >>> ... Ingres also requires mods to the kernel... > >> > >>Actually, Ingres has a locking pseuodo device driver. I do not think that > >>adding a "device" driver is equivalent to "mods to the kernel" since you > >>are not changing kernel source code. > > > We, at BRL have a lock daemon supplied by RTI. As far as I know, we are the > only such installation. It was developed for us by RTI, at our insistence, > as a prototype to aviod the kernel mod required by INGRES 2.0. We have been > using it successfully since June 1985. I have been trying to persuade RTI > to support it as an alternative; but they won't commit themselves. > > Maybe a little pressure from netland... Whether or not these are actually "mods to the kernel" is not important (the mods in the past where actually very small). What is important is that it is still required to build a different version of the kernel for Unix sites running Ingres EVERY time a new version of Ingres appears. This causes many headaches when you are trying to keep consistent versions of the kernel about. The current arrangement leaves the installation of Ingres to people who DON'T HAVE THE RESPONSIBILITY FOR THE FUNCTIONALITY OF INGRES. When RTI's technical support says "If you upgrade to the new version your problem will be fixed and we cannot give you a bug fix for the out of date version" there is not much recourse but to wait for the system people. My comment to RTI (and they've heard it from us before) is GET THAT BLASTED DAEMON WORKING IN ALL UNIX SITES SOON... At least give us a commitment and time frame. I don't know if Ed Gould knows where from he speaks, but if he does, the lock daemon seems to be a viable solution. Note, that this problem is going to be particularly acute this year with TWO new versions (far enough apart to justify moving to both) of Ingres on Unix 4.2/4.3. _______________________________________________________________________________ Jack Griffith jackg@tektronix - (503) 627-6352 \ 50-454 Systems Services - Data Base Management, Tektronix Inc. _____________________________________________________________________________
eric@osiris.UUCP (Eric Bergan) (02/12/86)
> We, at BRL have a lock daemon supplied by RTI. As far as I know, we are the > only such installation. It was developed for us by RTI, at our insistence, > as a prototype to aviod the kernel mod required by INGRES 2.0. We have been > using it successfully since June 1985. I have been trying to persuade RTI > to support it as an alternative; but they won't commit themselves. > > Maybe a little pressure from netland... Last I had heard, the lock daemon was significantly slower than doing the locking as part of a device driver. Is this still true? In doing some quick checks of how other database systems do locking, I have learned that they largely lean towards the use of shared memory under System V. Those that support BSD at all use lock daemons through sockets, but at significant decrease in performance. For our own application, which is running queries at high transaction rates, I actually prefer the device driver approach so that I can get every iota of performance out of the system that is possible. -- eric ...!seismo!umcp-cs!aplcen!osiris!eric