hedrick@athos.rutgers.edu (Charles Hedrick) (11/01/90)
I posted a couple of things to this group about 6 months ago that reflected a set of serious problems we had with Ingres. I tried to avoid being critical, but I think my overall dissatisfaction with the state of Ingres 6.x, x < 2, came through. Thus I think it is only fair to note that we've been using 6.3 in an undergraduate database course this semester, and as far as I can tell the problems we saw with early releases of 6 have been fixed. The contrast with last semester is quite striking. We were displeased enough that I was considering moving to another database system. I didn't, because attempts to evaluate alternatives left me with a queasy feeling that we'd be moving from the frying pan into the fire. My attempts to survey the community suggested that Ingres was by far the most commonly used commercial database system in university database courses, and generally people were pleased with it. I'm now glad we stuck it out. We are still having various strange events, but these events seem to be the problems you'd expect with students trying to use a product as complex as Ingres when they have no database experience. E.g. somebody ^Z's a job, starts another job on the same database, and wonders why the system seems to be locked, or two students working on the same database try to destroy the database and retrieve data from it at the same time... The biggest problem seems to be that students now and then report they can't connect to the server. As far as I can tell this is because they tend to have more than one session active at a time, and have simply come up against our configured limit on simultaneous sessions. (They also don't bother to tell the systems staff about these things, or we would have done something.) As far as I can tell, we have had no crashes of the servers (or if we have, they have managed to restart themselves automatically). I'd like to publically thank the local office of RTI for their help in working with the earlier and more problematic releases. What could be done by support, they did. Our configuration is 30 Sun 3/50's and 3/80's with a 3/80 acting as a server. The 3/80 has 16MB of memory and an HP 760 MBbyte SCSI disk drive (of which we are using only half, in order to improve average access time). Now and then we see signs that a bit more CPU power would be desirable on the server, but this configuration seems to be able to handle the load of around 20 students hacking. I'm going to see if we can manage to move to a Sparcstation for the server at some point.
pavlov@canisius.UUCP (Greg Pavlov) (11/02/90)
In article <Nov.1.00.04.36.1990.16492@athos.rutgers.edu>, hedrick@athos.rutgers.edu (Charles Hedrick) writes: > I posted a couple of things to this group about 6 months ago that > reflected a set of serious problems we had with Ingres. .... > Thus I think it is only > fair to note that we've been using 6.3 in an undergraduate database > course this semester, and as far as I can tell the problems we saw > with early releases of 6 have been fixed. Our problems, on the other hand, have NOT gone away. And they include deadly serious ones (literally). > We were displeased enough that I was > considering moving to another database system. Our only alternative at this point appears to be a lawsuit. And we are moving in that direction. > We are still having various strange events, but these events seem to > be the problems you'd expect with students trying to use a product as > complex as Ingres when they have no database experience. The people reporting "strange events" on our systems (including myself) include a core that has worked with INGRES for five years, starting with version 2, on platforms spanning 80286-based PC's to RISC minis. > As far as I can tell, we have had no crashes of the servers.... We count ourselves lucky if we manage to survive the day with "only" one. > I'd like to publically thank the local office of RTI for their help in > working with the earlier and more problematic releases. We have had a series of "problem tickets", "bug reports", and endless promises from technical, administrative, and sales staff and executives who talked to us once and then disappeared. A lot of "I will get the support and technical people working together on this" nonsense. > What could be done by support, they did. We got a lot of words and promises. The latest we have been told is the time-honored "you are the only one we know of on this platform with these problems". While our sample size is admittedly small (one other site), we know that this is pure bull. > Our configuration is 30 Sun 3/50's and 3/80's with a 3/80 acting as a > server. The 3/80 has 16MB of memory and an HP 760 MBbyte SCSI disk > drive (of which we are using only half, in order to improve average > access time). .... We are (now) trying to keep INGRES afloat on a DEC 5000, acting as a server. It has 48 megs and a set of HP 760 MBbyte SCSI disks (of which we are only using half.... etc). We are also attempting to run it on a DEC 5810, a DEC 5400, and several DEC 3100's. We have experienced server crashes, corrupted tables, corrupted indices, disappearing committed transactions, and endless "nuisance" problems on every one of these machines. The state of INGRES 6 on our chosen platforms - DEC RISC-based machines - and the company's lack of accountability and rsponsibility for its product has, without exaggeration, has come close to destroying the credibility and worth of our organization. It has been kept afloat only because we have a core group of computing people who have worked a steady pace of 60 to 70-hour weeks for the past 8 months to keep us afloat. INGRES 6 has been and continues to be a nightmare for us. With all due respects to Charles Hedricks, whose name has been well-known to me for some years. greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
jh@efd.lth.se (Joergen Haegg) (11/02/90)
In article <2987@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: >In article <Nov.1.00.04.36.1990.16492@athos.rutgers.edu>, hedrick@athos.rutgers.edu (Charles Hedrick) writes: >> fair to note that we've been using 6.3 in an undergraduate database > > Our problems, on the other hand, have NOT gone away. And they include > deadly serious ones (literally). Is these problems serious in univ.ingres 8.1 also? -- -- Joergen Haegg jh@efd.lth.se postmaster@efd.lth.se System manager @ efd 046-107492 Lund Institute of Technology Sweden
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/04/90)
On 2 Nov 90 07:06:02 GMT, pavlov@canisius.UUCP (Greg Pavlov) said:
pavlov> In article <Nov.1.00.04.36.1990.16492@athos.rutgers.edu>,
pavlov> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
hedrick> [ ... pleased that a lot of small problems with Ingres are
hedrick> corrected in Ingres 6.3 ... ]
pavlov> [ ... having hell with Ingres 6.3 ... ]
pavlov> The state of INGRES 6 on our chosen platforms - DEC RISC-based
pavlov> machines - and the company's lack of accountability and
pavlov> rsponsibility for its product has, without exaggeration, has
pavlov> come close to destroying the credibility and worth of our
pavlov> organization.
Because you have chosen the wrong platforms. Sorry about saying that.
DEC 5000, 58000, etc... systems are running essentially ALPHA or BETA
system software (4.0 is still quite loose), compilers (although 2.1
seems to be less buggy than previous releases), and hardware (the
processor boards seem to be fairly buggy). In other words they are as
full of holes as emmenthal. I am suprised you have managed to get Ingres
running at all. I know of DEC RISC systems that crash with virtually
nothing running on them.
Let me say that you have been somewhat unwise to become the guinea pigs
for DEC in runnning a major database application as a test of their
newly released systems. If you want reliable operation don't use as
platforms for major and complex application packages machines that have
been rushed to market yesterday. Hey, as an example just Sun moving to
SunOS 4.1 on the same hardware has broken so many things in so many
little ways...
Also, don't expect that such (necessarily quickly ported) packages will
run reliably on such a shifty base. Even on much more mature systems
many such packages tax them hard enough that they have to be carefully
adapted to work around the bugs of the underlying platform. This is an
essential process in making a large program reliable to the end user,
and I can understand that DECsystem Ingres may not have yet been so
adapted, also because Ultrix and hardware releases are incessant and
very different from each other.
DEC RISC systems, hardware and software, are very good price/performance
systems, but not yet reliability wise. You pay your money, you take your
chances. Don't bad mouth Ingres, which may or may not deserve it,
without considering the other, more obvious, possibilities.
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpavlov@canisius.UUCP (Greg Pavlov) (11/05/90)
In article <PCG.90Nov3175255@athene.cs.aber.ac.uk>, pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > Because you have chosen the wrong platforms. Sorry about saying that. > DEC 5000, 58000, etc... systems are running essentially ALPHA or BETA > system software (4.0 is still quite loose), compilers (although 2.1 > seems to be less buggy than previous releases), and hardware (the > processor boards seem to be fairly buggy). In other words they are as > full of holes as emmenthal. > Do YOU actually use one of these systems every day or is this another one of those rumors you are so fond of cluttering up comp.arch with ? We run a variety of applications, from simple to complex, for a rather large number of people. We do not have problems with the stability of anything but INGRES. Our systems and other applications crash rarely; INGRES crashes daily. > Let me say that you have been somewhat unwise to become the guinea pigs > for DEC in runnning a major database application as a test of their > newly released systems. In November of last year, INGRES sold us licenses for DEC RISC machines. It also demands and receives annual maintenance fees. There was no mention of the product being so unstable that we need to have a programmer stand by round the clock to recover from and clean up after server crashes. If we are, indeed, guinea pigs, it is for INGRES's benefit, not DEC's. But I do not think that the termo "guinea pig" is appropriate, since that infers that someone is conducting an experiment to gain knowledge and use it for some useful purpose. To the best of our knowledge, INGRES is simply ignoring the problems and pretending that they do not exist. (On another note: I have received messages from other sites, running other hardware platforms, reporting many variations of the same problems. I thank you for taking the time to write; it made us feel better [at your expense], in that the suspicion that we are somehow botching this up was dissipated. I also received a message from a "senior" member of the INGRES user group who told me that, unlike several other platforms, ULTRIX is not one that is known to be a "problem platform". Given our experiences, I offer my condol- ences to those attempting to work with the "problem platforms": it's hard to imagine what working with those must be like). > > Don't bad mouth Ingres, which may or may not deserve it, > without considering the other, more obvious, possibilities. I have worked on approximately 12 different computer platforms over the past eighteen years and have worked with at least half a dozen data managers and DBMS's for the past 14. I considered more possibilities than you are aware of before posting my message. greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/08/90)
On 4 Nov 90 20:21:47 GMT, pavlov@canisius.UUCP (Greg Pavlov) said:
pavlov> In article <PCG.90Nov3175255@athene.cs.aber.ac.uk>,
pavlov> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> Because you have chosen the wrong platforms. Sorry about saying
pcg> that. DEC 5000, 5800, etc... systems are [ ... ] as full of holes
pcg> as emmenthal.
Well, things are improving fairly fast, and maybe "full of holes as
emmenthal" is too much -- but they are far from mature. You can now run
timesharing type operations without too many suprises, and the system
anyhow comes up quickly enough :-).
pavlov> Do YOU actually use one of these systems every day or is this
Yes -- I also occasionally assist the system managers in fairly frequent
problem resolution. These systems were very correctly described by DEC
as experimental machines, at the moment of the sale about one year ago.
The chance taken was IMNHO perfectly justified -- the price was great,
the performance was great, tight reliability and maturity were not
needed. Some crash here and there is nothing for a timesharing service,
and users are patient...
pavlov> another one of those rumors you are so fond of cluttering up
pavlov> comp.arch with ?
Would you please demonstrate how can I clutter up comp.arch with
rumours? aren't you exxagerating a bit here? should not you be more
cautious with what you say and gross generalizations thereof? You seem
very quick at attacking people (first Ingres then me).
pavlov> We run a variety of applications, from simple to complex, for a
pavlov> rather large number of people. We do not have problems with the
pavlov> stability of anything but INGRES. Our systems and other
pavlov> applications crash rarely; INGRES crashes daily.
Maybe you have not reflected on the idea that Ingres is an extremely
complex application. Maybe you are not familiar with the architecture of
a large DBMS. It actually is about as complex as the OS itself, indeed
much more, and taxes the underlying OS services and the hw very
severely.
In particular recent DBMS technology uses otherwise little used aspects
of the sw and hw, e.g. to implement multithreading, high bandwidth
server/client data sharing, etc... A large DBMS is not just like a large
application program -- it is far more sophisticated. It is a systems
program.
The result is that most (probably all) large database managers contain
workarounds for many OS bugs or hw problems that are not exercised by
any other program, even on mature systems.
Think about this: when BSD Unix was first ported to the VAX, it had to
contain a few workarounds for hardware problems that were never tickled
by VMS, at thousands of sites.
pavlov> In November of last year,
Uh oh. November last year I would not have run 'cat' on a DECsystem if I
had to depend on it :-). When were these machines officially announced?
I think that one year ago they were still unofficial. I tried to port
some of the GNU sw there and it sort-of worked. I was happy enough, even
if I had to battle the compilers, and a buggy processor board. To the
best of my knowledge DEC themselves November last year described the
MIPS based systems as alpha/beta releases.
Also, since November one year ago there have been many major and bug fix
Ultrix and processor board releases. Are you sure you and the Ingres
guys are running exactly the same release of both hw and sw? If not,
they may have serious difficulties reproducing your problems, and thus
they may dismiss your reports.
pavlov> INGRES sold us licenses for DEC RISC machines.
What's written on those licenses? Usually something like "you pay your
money you take your chances". The chances seem to be pretty poor when
you speak of running a newly released port of a major package on a newly
released hardware running newly released systems software. A lot of
people are still spitting blood trying to port major packages to SunOS
4.x on the SPARC, or to AIX 3.x on the RS/6000, etc...
I remember somebody saying that to port a very large application just
from one compiler release to the next on a mature system took 200
programmers one year and a half of work... This was for 7 million lines
of code. It turns out that is 300 man years, or 24 thousand lines
retested and updated per man year. Probably a bit low -- if you are
lucky you can do it faster.
Ingres probably is an order of magnitude smaller (hundreds of thousands
of lines of code, not millions), and admittedly complexity decreases
more rapidly than size. But we have not just change of compile release;
we have problems across the entire hw/sw platform. This means probably
much more than a few man years. Did Ingres have the time (not just the
will) to deploy even just a few man years before the release of their
product? Uhmmmm.
The Ingres DBMS is IMNHO generally very good; and DEC MIPS based systems
are IMNHO very good too, just not mature enough for critical service.
So, I would not bet *my* reputation on a combination of just released
platform and just released DBMS port. Nobody does miracles. No matter
what they say:
pavlov> It also demands and receives annual maintenance fees.
Which normally entitle you to *report* bugs. You may, ex gratia, also
receive some updates, which may or may not fix those bugs; the media on
which the updates are sent to you are guaranteed defect free.
pavlov> There was no mention of the product being so unstable that we
pavlov> need to have a programmer stand by round the clock to recover
pavlov> from and clean up after server crashes.
Does it work for one hour for one user? Well, it *works* :-). Everything
else is your problem. I would venture to predict that if you offer
Ingres enough cold cash they will send to you their entire
implementation team just to work on your machine and configuration to
make it work to your specification, getting around any OS or hw bugs,
and ignore any other work they are doing.
At moments you seem to be arguing that you should not have to bother
about all this -- you pay, you have a contract, you want a product with
few problems and prompt service on them. Hahahahahahahahahaha. Good one.
Now, if you instead told us how it crashes and your analysis of the
problems maybe we could try to guess how much hope to have that DEC or
Ingres will fix them up soon, at least on the technical side.
For example: many DMBSes exert very badly the virtual memory subsystem
of the OS. Ultrix has known problems in that area, which DEC seems
unconcerned with (they can be solved by adding more memory :->).
Also, many DBMSes do things with the IPC primitives that nobody else
does (I read a report of one doing thousands semaphore operations per
seconds). If SysV IPC is being used, that can be a problem: many
BSD/SysV hybrids have many bugs in that lightly used area. Which release
of the compiler was used to compile Ingres? This can be a fairly
important bit of information.
And so on.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukrobinson@durham.med.unc.edu (Gerard A. Robinson) (11/08/90)
In defense of Mr. Pavlov here, the Sun version of INGRES 6.3 has had significant patches applied to it, some for shared cache problems (more than one database server), some for b-tree corruption crashing the server (which of course caused the b-tree corruption in the first place), some for indefinite hangs where a semaphore gets 'lost in virtual space'. There have been seven patches that I've heard of, six of which we've received (or will, the seventh was actually a patch of a patch, a real son-of-a-patch :-) These are not intrinsically hardware related, as I know that the semaphore and shared cache problems appeared under VAX/VMS as well. Now on the other hand, the DS3100s that I've had to play with seem doubly damned. I have a little, personal program that I always build called 'where' which prints 'whoami@host:/current_directory umask tty=TERM'. Well the DS3100 would compile this program fine, and run it well, as long as the directory was an even number of characters in length. An odd number? Core dump. So by doubly damned I mean: 1st, its a RISC architecture chip with more restrictive data alignment problems (SPARC systems also exhibit these restrictions), and 2nd, its done with little-endian data types (which to my knowledge other MIPS user/makers *don't* use). But on the other hand, INGRES version 5 does seem quite stable on it now. More later perhaps ... Gerard Robinson
pavlov@canisius.UUCP (Greg Pavlov) (11/11/90)
In article <PCG.90Nov7195806@teachk.cs.aber.ac.uk>, pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > ....aren't you exxagerating a bit here? should not you be more > cautious with what you say and gross generalizations thereof? Yes, you are right and I apologize. I will take your advice (and suggest that you do the same). Actually, I believe that you are correct in your assessment overall: the problem is not INGRES, but the DEC platform. And, taking this a step fur- ther, it is patently obvious from the letters that I received that all platforms on which INGRES 6 runs are similarly flawed - some less, some more, but all (surprisingly) with the same fatal flaws. So the solution is really very simple: we, using your thorough "analysis" as a guide, convince all the vendors involved to correct their systems. They can save a lot of time and effort by working together since, as I noted, they all have the same faults. Once this is done, INGRES should operate without a hitch, managing our databases instead of munging them. A beautiful concept. I bet Ashton-Tate wished it had thought of it. And Oracle.... and... thanks for the insights, greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org (the alternative is tougher but one that INGRES is rumored to be working on: fixing the bugs in INGRES. Version 6.3 is supposed to be out now for some platforms, with positive results. I hope so, both for INGRES's sake and its customers. I sincerely believe that INGRES was among the very best of the DBMS vendors for a long time, producing an excellent system but not knowing how to market it. They seem to have stumbled badly with the new server architecture. I would really like to see them recover and get back on track. And with better marketing :-).