Re: Oracle V6 & Raw Partitions

From: John Peach <epeas_at_abds7.aberdeen.chevron.com>
Date: 2 Sep 93 07:35:00 GMT
Message-ID: <1993Sep2.083500_at_abds7.aberdeen.chevron.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?

From a recent posting to this group :-)

I suggest you get a copy of "Making the Decision to use UNIX Raw Devices", Number 2 in the Oracle NPST Technical Monograph Series by Cary V. Millsap, Oracle National Product Specialist Team (cmill_at_us.oracle.com). It lists the following as prerequisites for going raw:

Use raw devices only if the UNIX operating system does not offer the capability for direct I/O through the UNIX filesystem.

Use raw devices for Oracle files only if the site has sufficiently brutal transaction and query volume that disk I/O is the performance bottleneck.

Use raw devices for Oracle files only if the site has at least as many raw disk sections as it will have Oracle tablespaces.

Use raw devices for Oracle files only if the site has enough disk space that it can afford over-allocation of small Oracle tablespaces.

Use raw devices for Oracle files only if the site has multiple experienced Oracle and UNIX administrators.

From the summary:

Using raw devices can help performance at the margin in some installations, but raw I/O will not benefit most Oracle sites.

|>
|>
|> Thanks in advance.
|> Paulj.
 

-- 
                               John Peach
                           Chevron (UK) Ltd.
   Ninian House, Crawpeel Road, Altens, Aberdeen, AB1 4LG, Scotland.
   Internet: epeas_at_aberdeen.chevron.com        Phone: +44 224 242637
Received on Thu Sep 02 1993 - 09:35:00 CEST

Original text of this message