At 08:50 AM 6/5/99 +0900, Tatsuo Ishii wrote:
>
>On the other hand the LED was on only every few secs while running
>Oracle. I heard that Oracle has a "REDO log file" and a log is written
>into there when a transaction is committed. If so, apparently Oracle
>does not issue sync() or fsync() every time a transaction gets
>committed. I don't know how Oracle guarantees the log be written into
>the disk without sync() or fsync() at the commit time, but seems
>something like it is one of the most important technique to enhance
>the performance of PostgreSQL.
>Does anybody have an idea on this?
It's a well-known bug in the current Oracle release for Linux,
the redo log is supposed to be fsynch'd on commitment. Oracle
does fsynch on other Unices. It will be interesting to see if
the upcoming 8.1.5 (or "8i", "i" for internet, as it's called)
will have the bug fixed. This still won't cause a lot of
disk thrashing in a recommended Oracle installation as the
redo log should be on a separate spindle from any db spindles,
and Oracle grabs the entire file when the db's created in
order to increase the odds that the file will be one sequential
series of blocks (of course, real Oracle studs use raw disks
in which case the db can guarantee serial block writing).
There's a separate demeon hanging around that writes dirty
database pages to the disk at its leisure.
Of course, if I've understood past postings to this list,
Postgres also fsynch's after read-only selects, too, and
my own experience would seem to confirm it (putting a
string of selects in a transaction makes the disk get
quiet, just as it does with inserts).
I can guarantee that Oracle NEVER does that :)
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net