Re: Unix Filesystem vs Raw Partition

From: <jpope_at_mojo.europe.dg.com>
Date: Fri, 14 Oct 94 11:32:51 GMT
Message-ID: <1994Oct14.113251.12844_at_mojo.europe.dg.com>


Lee E Parsons (lparsons_at_world.std.com) wrote:
: Paul Zola <pzola_at_us.oracle.com> wrote:
: >
: >The Oracle RDBMS uses one of these two system calls to guarantee that
: >the data associated with a transaction has "hit the disk" by the time

: >that the COMMIT returns.
 

: Will the entire system be synced on each commit? I would have thought
: that this would have had performnce implications. I had always figured
: that all writes to the redo log would be backed by a O_SYNC and the
: entire DB would be synced at a checkpoint. This is the least amount of
: syncing I can see that still ensures integrity. A sync only at commit
: would still leave you at risk if uncommited data had been flushed out
: of the SGA and writes to the redo logs was still pending.
 

: Any white papers on how this works? BTW, You should have answered
: this on Monday. I would have been too busy working then to bother
: you. :-}
: --
: Regards,
 

: Lee E. Parsons
: Systems Oracle DBA lparsons_at_world.std.com

This is incorrect. Only the redo log writer issues sync'ed writes at commit time, which is what guarantees your transaction can be re-applied from the redo's in the event of a system crash. The actual block changes, held in the block buffers, get written out later by the dbwr at timeout intervals or at a checkpoint, implicit or otherwise. Whether you have raw i/o or not is irrelevent to this process - all you achieve is avoiding many software layers in your UNIX kernel which map logical block addresses to physical disk positions, since Oracle is doing all that for itself. Note that in UNIX systems that implement logical disk conecpts, such as striping from the O/S as opposed to on a hardware product (like Clariion), then some mapping still has to occur, so there may less benefit. Received on Fri Oct 14 1994 - 12:32:51 CET

Original text of this message