Re: Oracle V6 & Raw Partitions

From: Lee Parsons <lparsons_at_exlog.com>
Date: Thu, 2 Sep 93 14:04:11 GMT
Message-ID: <1993Sep2.140411.3706_at_exlog.com>


In article <paulj.746933340_at_hawk> paulj_at_adied.oz.au (Paul Jowett) writes:
>
>I have just completed some benchmarking of an Oracle V6
>database on SunOS (4.1.2) to see if using raw partitions
>instead of SunOS files will make a significant performance
>improvement. The results indicate that the database runs
>faster with normal files. This is counter-intuitive and
>counter-documented.
>
>Could anyone give some explanation to this?

What did your numbers look like? What kind of test was it? V6/V7? Can I use your bench as an example the next time I have a raw vs cooked argument with someone? :-}

The only case I can think of where cooked would actually be BETTER is if your bench did many full table scans of the same set of tables or your SGA was too small.

The logic runs something like this. Raw Partitions are generally faster for I/O bound processes because they (among other things) avoid a worthless pass through the buffer cache. The buffer cache is of no use to oracle, so the argument goes, because it is often smaller than the SGA and doesn't do anything to keep special information that should not be flushed out. ie) dc_tables & free lists.

Well that makes sence for most systems but what hapens for SunOS where all of RAM can be used to as a buffer cache. Now you have a 124mb acting as a cache instead of 12mb. This is further dramatised if you do a full tablescan of a large file (over 5 oracle blocks). Under Raw this file would be read into the SGA and immediately flushed. so the Next read would have to hit the disk again. Using Cook files some of this guy could still be in the buffer cache. And using SunOS all of it.

-- 
Regards, 

Lee E. Parsons                  		Baker Hughes Inteq, Inc
Oracle Database Administrator 			lparsons_at_exlog.com 
Received on Thu Sep 02 1993 - 16:04:11 CEST

Original text of this message