Re: Filesystem a factor in DB transaction speed ?

Vladimir M. Zakharychev wrote:

> Simply because Oracle does not operate with small files, thus it does not
> need them to be aggregated (the obvious exclusion is BFILE which is stored
> outside the db). Internally Oracle operates on blocks of raw data (that's
> why raw devices provide so far the best performance - they don't have any
> fs-related alignment/chunking of data as well as fs-level caching
> overhead). These blocks are cached in the buffer cache which resides in
> RAM thus eliminating the need to perform physical I/O altogether once the
> block is read into buffer cache and until it is purged. On well designed,
> programmed and configured Oracle dbs logical to physical I/O ratio should
> be 10/1 or better (that is, buffer cache hit ratio should be at least
> 90%). Such ratios make FS read performance fairly insignificant as at all
> times at least 9/10 of all data blocks are cached and do not require
> physical disk reads. Of course, write performance should also be good,
> especially for redo log devices, but I don't see how any fs in particular
> may help speeding up disk writes as effectively as your disk array
> hardware cache buffer :) To sum up: file systems are designed to store and
> retrieve files effectively, but Oracle's not about files - it's about
> structured data. Files are employed just because they are the common mean
> for storing data and almost all operating systems provide similar abstract
> interfaces for operating them. Yet the best I/O performance in Oracle is
> achieved on raw devices where no file systems get in the way.
>
> Correct me if I'm wrong at any point.
>

Vladimir:

That makes sense ! I wasn't aware how Oracle handled its data internally. Since they do it how you described, it makes sense that FS performance does not have much of a say in the whole affair... Thanks for a great response !

Volkmar Received on Sun Dec 02 2001 - 10:30:47 CST