Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!feed.news.tiscali.de!newsfeed01.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail From: Rick Denoire <100.17706@germanynet.de> Newsgroups: comp.databases.oracle.server Subject: Re: Index compression vs. table compression Date: Sun, 02 Jan 2005 04:56:27 +0100 Organization: T-Online Lines: 40 Message-ID: References: <4hi3t0l7efahpe916hmmf1a82clacllvs9@4ax.com> <41d1e3ad$0$1084$afc38c87@news.optusnet.com.au> <41d213aa$0$5112$afc38c87@news.optusnet.com.au> <41d3480c$0$1084$afc38c87@news.optusnet.com.au> Reply-To: 100.17706@germanynet.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.t-online.com 1104638190 02 13585 d-ibraR1J+-B-KD 050102 03:56:30 X-Complaints-To: usenet-abuse@t-online.de X-ID: SXM0BMZLweTAomk-ZcCZajU9Rq7ujT6RDhqPzqbkEVS7wTYGDC5z6U X-Newsreader: Forte Agent 1.7/32.534 Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:232533 "Howard J. Rogers" 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