Re: Hardware RAID vs. Software RAID

"Anna C. Dent" <anacdent_at_hotmail.com> wrote in message news:<HTjlb.79755$Ms2.40052_at_fed1read03>...
> Chuck Lucas wrote:
> > "Anna C. Dent" <anacdent_at_hotmail.com> wrote in message
> > news:Ye%kb.79328$Ms2.67542_at_fed1read03...
> >
> >>Chuck Lucas wrote:
> >>
> >>>"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
> >>>news:1066587431.204277_at_yasure...
> >>>
> >>>
> >>>>You are correct on all points.
> >>>>
> >>>>But what version you implement can make a big difference. I'd stay away
>
> >>>>from RAID 5 and vendor RAID
>
> >>>>implementations with numbers like 2 and 4.
> >>>
> >>>
> >>>What's wrong with RAID 5?
> >>
> >>With Raid-5 the redundancy information is stripped across all disks.
> >>For EVERY data block which is written to a RAID-5 volume the parity
> >>block must be recalcuated and also written to disk. For all intents
> >>and purposes RAID-5 doubles the number of write operations to disk.
> >>As the percentage of WRITE to READ operations increases available
> >>useful/application disk throughput decreases.
> >>
> >
> > Wow! I didn't expect this much of a response. Thanx, folks, for the input.
> > I, OBVIOUSLY, have some more research to do, huh?
> >
> > But I did notice throughout this that it seemed as though you guys were
> > talking about software RAID5. I'm using hardware RAID5...does that make any
> > difference in your opinions?
>
> The major difference between hardware based RAID-5 & software based
> RAID-5 is performance. With S/W RAID-5, such as NT used to implement,
> the actual PC computed the parity block; which is somewhat CPU
> intensive. This drains even more resources from the application.
> With H/W RAID-5 the parity calulated on the controller thereby "giving"
> those CPU cycles back to the application.
>
> In round numbers and folks will argue about the ROM SWAG to follow;
> accessing RAM is three orders of magnitude (1000 times) faster than
> transferring the data blocks from the platters into memory which is
> 1000 times faster than moving the heads of the disk drive to the desired
> cylinder and then wait for the platter to spin the data under the heads.
> The bottom line is that I/O operations are about 1,000,000 time slower
> than accessing data in memory. Therefore it is best to minimize the
> number of READS or WRITES which are done to & from disk. RAID-5 trades
> disk space (gives you more) but you pay a perfromance penalty. Some
> folks can live with this trade-off, while others need PERFORMANCE and
> are willing to pay for it (by buying more/better/faster disks &
> controllers).

myth.

the overhead of logical IOs is far greater than you might think. I have constructed a full table scan on a single, isolated 4 disk RAID 10 volume of a 240 MB table that took 12 seconds to execute against a just-started instance (read: zero blocks cached), took 9 seconds to execute against having the entire table in the buffer cache. (willing to post trace files upon request, don't have them at home).

if you have a good storage subsystem (read multiple RAID 10 volumes), with a good dfmbrc, well matched to the OS I/O size, an adequate number of controllers, adequate number of disks, good I/O layout, and good RAID controller read-ahead behavior, this can be less than a factor of 10. It can be as small as 3.

then again, if you're advocating using RAID-F, cache it all in memory and avoid disk I/O at all costs.

I guess the numbers that would matter most, are, gather system stats and see what oracle thinks they are.

Pd Received on Wed Oct 22 2003 - 03:01:23 CDT