Re: Is Raid 5 really that bad for Oracle?

My argument is this:

1. Mirroring is excellent for resilience. Striping is excellent for performance (as long as the striping is done with large enough granularity as not to introduce a concurrency problem). Combining the two technologies makes for excellent resilience and excellent performance.
2. But mirroring is expensive per byte of storage. Hence RAID levels 2, 3, 4, 5, and 6 were proposed. Their design goals were to lessen the expense-per-byte of storage of RAID level 1 (mirroring). For example, with G=5 RAID level 5, the price of resilience per byte of storage is 5/4 of a 4-disk array instead of 8/4.
3. But the additional parity operations required to run RAID [23456] produce a performance penalty. The performance penalty is so bad (4:1 for many common Oracle operations) that it begged for a solution: namely, the introduction of non-volatile cache and a complicated kernel (more lines of source code than Oracle7.1) to run it all. So, as long as the cache is big enough to stay ahead of your sustained throughput, a RAID level 5 array can perform almost as well as a well-configured array that uses levels 0 and 1 combined.
4. But the RAID level 5 array is deficient in a number of important ways (performance degradation during partial outage as Howard mentioned, worse availability performance, worse read performance [contrary to popular belief], inability to take online backups with a simple re-silver operation, etc.). And the cache and microcode make the RAID level 5 array more expensive than the 0+1 or 1+0 array, which defeats the whole purpose of inventing RAID level 5 in the first place.

I'm not telling you not to use RAID level 5 (we use it for low-throughput systems with flexible availability requirements). Just don't assume that it's cheaper than using RAID levels 0 and 1 for high-throughput systems. The insidious thing is that your initial procurement cost is probably cheaper if you use RAID level 5, but if you don't figure out in your initial capacity plan that "disk sizing" means counting I/O calls, not counting bytes of storage, then you're in for a lot more expense than you thought, if you go the RAID level 5 route.

By the way, did you notice in the original Chen/Katz/Gibson/Patterson/Lee paper that block-striped RAID level 1 is mathematically identical to RAID level 5 if you set G=2? So, in a sense, I'm a big proponent of RAID level 5. I just don't like the idea, for high throughput systems, of using parity group sizes bigger than 2 or buying the cache and microkernel. :-)

Cary Millsap

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:410ed541$0$25458$afc38c87_at_news.optusnet.com.au...
>
> "Joel Garry" <joel-garry_at_home.com> wrote in message
> news:91884734.0408021508.4bb00e13_at_posting.google.com...
> > niall.litchfield_at_dial.pipex.com (Niall Litchfield) wrote in message
> news:<b6beca79.0408020226.19e847f9_at_posting.google.com>...
> > > "joe bayer" <joebayerii(no-spam)@hotmail.com> wrote in message
> news:<qDPOc.1753$%J6.1677_at_trndny07>...
> > > > I am quoting from Jonathan Lewis's book, Practical Oracle 8i, page
206
> > > >
> > > > Raid 5 has an undeservedly bad reputation as far as Oracle database
> systems
> > > > are concerned. ....
> > > > However, for most small systems, it is almost necessary and
perfectly
> > > > acceptable; and for many large systems it is totally adequate.
> > >
> > > I'm not sure that I buy that it is almost necessary - it would be
> > > common in 'small' systems.
> > >
> > > I'd suggest that whether RAID5 is technically appropriate or not
> > > depends entirely on the application (that looks to be behind some of
> > > Jonathan's words too). No-one disputes (with the odd storage vendor
> > > sales droid exception) that RAID5 has a rather serious write penalty
> > > and so is slower than RAID10 (for the same capacity).
> >
> > I know a hardware-oriented IS manager who disputes that very thing.
> > Given a W2K 2+GHz dual Xeon, the argument is that the dual controllers
> > to the raid are going to be faster than the motherboard can hand
> > things off to a mirrored C drive. I get the "trust me" response if I
> > try to put anything anywhere but the raid-5. And there really isn't
> > enough room to do otherwise when you start adding in backups and arcs
> > and future data.
>
> Your IS manager is still missing the point, then. Generally, the write
> penalty for RAID-5 is going to be irrelevant, because no-one waits on DBWn
> to do its thing in any case (different matter for online redo logs, of
> course). The real bummer with RAID-5 is performance during a single hard
> disk failure, as each I/O operation gets translated into individual I/Os
for
> every disk in the stripe set. Oh, and the fact that it's not "I" anymore,
> but "compartively bloody 'E'". Cary's paper says it all, really.
>
> The write penalty during normal operation, in other words, is the least of
> RAID-5's problems. The main bummer is the READ penalty under failure
> conditions.
>
> And I say again, if someone doesn't have "enough room" to use anything
other
> than RAID-5, that sounds like an iffily cheap Intel box running Windows...
> and my recommendation would therefore be Access or SQL Server at a pinch.
> With sensibly-grandiose hardware, RAID-5 should still and always be the
last
> option to be considered -as I suspect you agree.
>
> Regards
> HJR
>
>
>
>
>
>
>
Received on Tue Aug 03 2004 - 00:34:34 CDT