Re: Is Raid 5 really that bad for Oracle?

"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.

Well, over a few systems in the last year I've seen a few of those failures, and the general attitude is "glad they didn't just fail, we can keep limping along until the problem is fixed, that is how it is supposed to work." So the expected performance is different, it's a special situation, which weakens that argument. Been too long since I've read the paper, need to check it out again, haven't yet read his response to this thread.

>
> 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.

I agree with the last, but not with your recommendation for the situations I see (which seem typical to me). That is, there already is a big production box, and the iffy little boxes are for DSS or web stuff that you can't justify some humongoid duplicate production box for. Would you really advocate a heterogenous enviroment for that?

In the specific case I've got in mind, there are also licensing issues that would be complicated, to say the least. In that same place, which is highly biased towards MS, I already see numerous problems with trying to do other things with SQL Server. Of course, I'm stuck with the numerous problems of OAS <sigh>.

>
> Regards
> HJR
jg

--
@home.com is bogus.
People dislike web based OEM: 
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=FOR4046336.995&p_id=500442.996&p_fromTAR=Y