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 Zakharychev (bob@dpsp-yes.com) http://www.dpsp-yes.com
Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet applications.
All opinions are mine and do not necessarily go in line with those of my employer.
"vrw" <linux4me2000_at_netscape.net> wrote in message news:9ud49q$ucb$1_at_news7.svr.pol.co.uk...
> Forrest Cicogni wrote:
>
> > While it is true that there exists file systems outperforming NTFS, the
> > point is nearly moot. Oracle depends less upon underlying file systems
> > than other programs, thanks to efficiently designed contiguous data files
> > and read/write buffering. File systems, fast or not, are the single
> > greatest source of bottlenecking, and the object of a well designed Oracle
> > database is to nearly eliminate disk I/O all together. Therefore, focus on
> > tuning and designing, and rely less upon finding faster hardware to make
> > up for poor implementations. The old adage still applies: "Fast computers
> > breed lazy programmers."
> >
> >
> >
> Forrest:
>
> I'm not sure you are 100% correct here.
> Are you saying that 'sidestepping' the issue of buffered reads and writes
> by means of an abstaction layer above the filesystem actually increases
> efficiency ? That makes no sense logically !
> May I back up my claim with a reference to the www.namesys.com website
> (ReiserFS' home page):
>
> Section "Why aggregate small objects at the File System Level ?"
>
> "Performance: It is most commonly the case that when one layers one file
> system on top of another the performance is substantially reduced, and
> Structured Storage is not an exception to this general rule. Reiserfs,
> which does not attempt to delegate the small object problem to a layer
> above, avoids this performance loss. I have heard it suggested by some that
> this layering avoids the performance loss from syncing on file close as
> many file systems do. I suggest that this is adding an error to an error
> rather than fixing it.
>
> Let me make clear that I believe those who write such layers above the file
> system do not do so out of stupidity. I know of at least one company at
> which a solution that layers small object storage above the file system
> exists because the file system developers refused to listen to the non-file
> system group's description of its needs, and the file system group had to
> be sidestepped in generating the solution. "
>
> I do trust Mr. Reiser's programming and mathematical background insofar as
> that he would not make this statement if it were untrue.
> From what I can tell, with Oracle's most used data types (numbers,
> varchar(2), dates, etc.) are very small and would lend themselves ideally
> to aggregating them in a small file.
> So you haven't really convinced me that using ReiserFS on an Oracle Linux
> system does not speed up performance.
>
> Can anyone illustrate why the ReiserFS/Oracle combination would not speed
> up things ? I'm not quite clear on why it would not.
>
> Regards,
>
> Volkmar
>
Received on Sun Dec 02 2001 - 06:37:46 CST
