Re: Raw Devices: Increased Performance?

From: Joel Garry <joelga_at_rossinc.com>
Date: 1996/07/18
Message-ID: <1996Jul18.141402.24958_at_rossinc.com>#1/1


In article <31ED5A94.15BC_at_jlcomp.demon.co.uk> Jonathan Lewis <ora_mail_at_jlcomp.demon.co.uk> writes:
>Joel Garry wrote:
>>
>> An unintended side effect is, poorly optimized apps that force too
>> many full-table scans will do better with raw devs...
>>
>
>I would have said that there is an opposing argument to that.
>
>If you do tablescans in Oracle, the data blocks are not kept in the
>SGA, so a repeated tablescan does the same set of disk reads agsin.

Oh, man, I was just assuming Oracle was smart enough to keep a small table in the SGA for repeated tablescans. Once again, burned by assuming Oracle did something right. Oh, I see, full table scans put the buffer at the LRU end of the LRU list, because it assumes if you are using a full table scan, you won't need the buffer again - so Oracle is only smart enough when it's under SMALL_TABLE_THRESHOLD. Not likely for most of the data, although possibly a good argument to not put all lookup codes in one table.

I've definitely changed my mind from thinking raw devs are almost a tossup to, don't use them unless you have to or can demonstrate their advantage.

Thanks,

jg

>
>With a file system, the disk reads may be satisfied from the
>file system buffer. With raw devices they will be physical
>reads. Result: a bad app collapses when moved to raw disk.
>
>---
>Jonathan Lewis
>ora_mail_at_jlcomp.demon.co.uk

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O
Received on Thu Jul 18 1996 - 00:00:00 CEST

Original text of this message