be@dde.uucp (Bjorn Engsig) (05/24/88)
In article <2728@geac.UUCP>, john@geac.UUCP (John Henshaw) writes: > In article <3102@edm.UUCP> news@edm.UUCP (news software) writes: > >From article <564@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov): > ># But using raw disk i/o per se doesn't guarantee anything, does it ? > > [ ] > In the case of UNIX, this is rather important. The UNIX kernel buffers > reads/writes from/to disk. This has the effect of not being able to offer > "guarenteed delivery" of buffers to disk. [ ] > UNIX does offer "raw data partitions" in which the program has control over > the disk space. However, all I/O to this area is "blocked I/O", [ ] > Raw disk I/O guarentees forced writes at the expense of throughput. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is not always the case. On our multi CPU Unix system, we run ORACLE, and it is always run on raw partitions for several reasons: 1) The guaranteed delivery is important for safety, and ORACLE offers it's own buffering mechanism which ensures the efficiency. 2) The throughput is *improved*, since all file system handling is bypassed. ORACLE is typically running on very few and very large files, say two files of ten to several hundred megabytes, and several levels of index blocks would be needed in the Unix file system. -- Bjorn Engsig @ Dansk Data Elektronik A/S, Herlev, Denmark Email: be@dde.dk Phone: + 45 2 84 50 11 Email: ..!uunet!mcvax!dkuug!dde!be Fax: + 45 2 84 52 20
pavlov@hscfvax.harvard.edu (G.Pavlov) (05/28/88)
> 2) The throughput is *improved*, since all file system handling is > bypassed. ORACLE is typically running on very few and very large > files, say two files of ten to several hundred megabytes, and > several levels of index blocks would be needed in the Unix file > system. > > -- > Bjorn Engsig @ Dansk Data Elektronik A/S, Herlev, Denmark > Improved over what ?? greg pavlov, fstrf, amherst, ny
allbery@ncoast.UUCP (06/05/88)
As quoted from <572@hscfvax.harvard.edu> by pavlov@hscfvax.harvard.edu (G.Pavlov): +--------------- | > 2) The throughput is *improved*, since all file system handling is | > bypassed. ORACLE is typically running on very few and very large | > Bjorn Engsig @ Dansk Data Elektronik A/S, Herlev, Denmark | > | Improved over what ?? +--------------- Imporved over (e.g.) Informix. Which is why there is now Informix-Turbo... which uses raw database partitions. (The difference was obvious when I moved a Unify database (30MB) from a file to a disk partition.) -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
pavlov@hscfvax.harvard.edu (G.Pavlov) (06/06/88)
In article <7873@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: > As quoted from <572@hscfvax.harvard.edu> by pavlov@hscfvax.harvard.edu (G.Pavlov): > +--------------- > | > 2) The throughput is *improved*, since all file system handling is > | > bypassed. ORACLE is typically running on very few and very large > | > Bjorn Engsig @ Dansk Data Elektronik A/S, Herlev, Denmark > | > > | Improved over what ?? > +--------------- > Imporved over (e.g.) Informix. Which is why there is now Informix-Turbo... > which uses raw database partitions. (The difference was obvious when I > moved a Unify database (30MB) from a file to a disk partition.) Sorry, I was obscure in my followup. My question related to a more basic issue: are these two dbms's "faster" than those that do not avail them- selves of this "feature" ? Or is it used to compensate for an overall design that otherwise produces second-rate performance ? Some time ago, a salesman for one of these companies pointed to the raw disk capability as an indication that his product was superior to those which were somehow less technically-advanced because they did not implement the same strategy. Yet, our evaluations showed that this dbms was at best equal in "speed" to others. This led us to what I believe was the correct conclusion, that the underlying data base engine was not as efficient as others. On the other hand, we also felt that large "black box" raw files would be more difficult to manage in a disaster/failure situation. Pointing out a technical feature as unique to a product is often a very powerful, if less-than-honest marketing technique. In some cases, the tecnical feature is present in other, competing, products, but no one thought that it was worth making an issue of (this "trick" goes back to the thirties at the very least, in general consumer product advertising). In other cases, such as the one above, it is needed to bring the product up to the level of competitiveness which it would not meet otherwise. greg pavlov, fstrf, amherst, ny
allbery@ncoast.UUCP (Brandon S. Allbery) (06/14/88)
As quoted from <573@hscfvax.harvard.edu> by pavlov@hscfvax.harvard.edu (G.Pavlov): +--------------- | Sorry, I was obscure in my followup. My question related to a more basic | issue: are these two dbms's "faster" than those that do not avail them- | selves of this "feature" ? Or is it used to compensate for an overall | design that otherwise produces second-rate performance ? +--------------- A little of both. There *is* a speed penalty derived from using ordinary Unix files, courtesy of indirect blocks (triple indirect blocks can KILL database response speed!). Unify has never advertized particularly loudly, but they've had raw databases since at least 3.0, which was out in 1984. Since Unify is generally pretty fast anyway in my experience, raw databases only add to the already-existing speed. Oracle is well known to have problems with batch-style transactions, which is why Oracle Corp. is releasing a new SQL processor for batch transactions. Without the new SQL (which is IN ADDITION TO the standard SQL, not replacing it!) you have to use raw database to get any semblance of speed in batch transactions. Informix-SQL isn't very fast, either. (I've used identical applications on the same computer running under Informix-SQL 2.10 and Informix 3.30; the pre-SQL Informix is much faster.) However, it is faster than Oracle in at least some circumstances; it's passable for most work. But it takes a MASSIVE speed hit when files get into double indirection (so does 3.30, it appears to be an artifact of C-ISAM), which Informix-Turbo is supposed to cure. So here it's a little of both. I couldn't say about others; I've never used them. (Well, a little Dbase III+ -- as little as possible -- but MS-DOS doesn't have raw devices so it's a moot point.) -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore