On Sat, May 10, 2008 at 9:55 AM, Daniel Fink <daniel.fink@xxxxxxxxxxxxxx> wrote: > To supplement Jared's response... Inline > > > Peter Teoh wrote: >> >> Unlike memory, where access time almost zero, accessing the disk is >> much slower. So sometimes I thought it will be better to spread out >> the data - thus enable simultaneous read by the different heads in the >> disk, just like those RAID design. Ie, fragmentation via >> distribution the blocks out in the disk can improve performance - can >> such things happened? >> > > In terms of reading data in memory, access time may be almost zero, but the > time required to read a block in memory is not thousands of times faster > than reading it from disk. I don't recall the exact figure from a Cary > Millsap presentation ("Why You Should Focus on LIOs"?)some years ago, but > the difference was something like 42 times. If you add in time required to > create a read consistent version, a single logical i/o could take much more > time than a physical i/o. I have yet to find Cary Millsap article, but this (by Don Burleson) is interesting: http://www.dba-oracle.com/oracle_tips_high_lio.htm One of the issues is the relatively high-cost of fetching an Oracle data block from disk. In theory RAM is 10,000 times faster than disk milliseconds vs. nanoseconds), but when you add-in the overhead of lock serialization and latches, a logical I/O might be less than a thousand times faster than a "physical" disk I/O. And this one from AskTom specifically on LIO is interesting: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6643159615303 > > -- > Daniel Fink > In general...I do agree that LIO involves lots of transaction handling, and CPU crunching...esp with Oracle read-consistency requirements. Thanks. -- Regards, Peter Teoh -- //www.freelists.org/webpage/oracle-l