Re: Raw Devices: Increased Performance?

From: Steve Dodsworth <Steven_Dodsworth_at_qsp.co.uk>
Date: 1996/07/18
Message-ID: <4slnoe$qip_at_mailhost.qsp.co.uk>#1/1


lots of people said the following :

>>>
>>> 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
>--
>Joel Garry joelga_at_rossinc.com Compuserve 70661,1534
>These are my opinions, not necessarily those of Ross Systems, Inc. <> <>

Full-table-scan tables can be kept in the sga via the cache keyword at table create time, god bless them

Bye,
Steve


| any similarity 'tween my opinions and that |
|  of my employers are purely hypothetical   |
|     and should give no cause for alarm     |
 --------------------------------------------
Received on Thu Jul 18 1996 - 00:00:00 CEST

Original text of this message