Re: RAID 5 performance

rstrouss_at_ix.netcom.com wrote:

>Paul Baumgartel <paulb_at_pcnet.com> wrote:
> <detail removed>
>>The application that I tested was a bulk data load. Part 1 of the load uses
>>SQL*Loader to load data from a set of ASCII files into staging tables. Part 2 of
>>the load executes a number of packaged procedures to find inconsistent data, compute
>>various values, generate primary keys, and create new versions of updated data; it
>>then loads the results into the actual application tables. This part of the load
>>does a significant amount of reading from the database as well as writing.
 

>>I tested the load on each database, with only the database instance under test
>>running. On the non-RAID array, the entire process, for one set of files, took an
>>average of 12 minutes. On the RAID 5 array, the average time was 32 minutes.
 

>>The write performance seemed particularly bad, as evidenced by write response times
>>observed in the SQL*DBA file I/O monitor. Response times ranged up to 150 ms on the
>>RAID, where typical values on the non-RAID disks were in the single digits.
 

>>YMMV, but this makes it pretty clear to me that, for this application at least, RAID
>>5 is not the way to go. Next I'm going to test RAID 0+1 (striped and mirrored), and
>>I'll post the results.
>
>We're setting up a RAID 5 envirronment on an HP 9000 box and I'm
>hoping the 32 meg cache will minimize the problem that you're
>encountering in your situation.
>
>

We use RAID 5 with 4meg write cache on an 8Gig DB with OLTP and some overnight batch. The write times go out to 200ms but this is ok. The tranaction screens work fine and we can afford longer batch updates, but cannot afford more disks. RAID 5 is the way to go if you can handle the poor write performance over the reduced cost of disks. The 4meg cache helps heaps, Can I borrow your 32Meg to see how that goes :-) Received on Fri Oct 27 1995 - 00:00:00 CET