Re: Index compression vs. table compression

"Howard J. Rogers" <hjr_at_dizwell.com> wrote:

>> Frankly, 25% is completely meaningless if you consider the enormous
>> impact that your theory about blocksize mismatch should have on DB
>> operations. Didn't we all learn that the really expensive part of DB
>> work consist of its "mechanical" components (e.g. moving heads on
>> disks)? And that accessing disks can be orders of magnitude slower
>> than the pure electronic access?
>
>I have no idea what you're on about now. I'm talking the exact same bit
>of spinning ceramic, formatted with exactly the same file system, yet
>two files internally organised into different Oracle block sizes, and
>still being able to measure a significant performance degradation.

What I meant is that if the mentioned blocksize mismatch leads to additional (and unnecessary) I/Os when working with filesystem buffering, then the effect should be considerable higher:

one Oracle block request is (alledgely) translated to two (or four, or...) single I/O requests when the Oracle blocksize is larger than the filesystem buffer blocksize, OR

one Oracle block request is satisfied by an I/O of larger (double, quadruple...) size, vastly consuming unnecessary resources.

I have made additional tests. I remounted repeatedly the ext3 file system switching from async (buffered) to sync (unbuffered) several times during heavy, long running I/Os. The effect was null, nichts, nada. Of course, this version of RHAS is using async_io because Oracle was linked with the corresponding option and the init parameters async_io and filesystemio_options set correctly (the main point being that RHAS has this ability in the kernel). Buffering is the one aspect, non-blocking I/Os the other. I still have to make more tests, perhaps using different platforms.

Regards
Rick Denoire Received on Sat Jan 01 2005 - 21:56:27 CST