Re: RAID5 - to split or not to split

Since RAID5 means that data is striped, of course read performance is OK. As soon as you talk write performance, however, RAID5 becomes something of a joke since it was invented back in the 70's to offer a cheap alternative to the fast, extremely expensive disks offered by IBM back then. So the focus was on limiting the number of disks. Today, where disks in general are cheap and caches are expensive, I really have a hard time figuring out why people buy RAID5 (few disks, cache required to compensate for the horrible write penalty) instead of RAID1+0 (more disks, no cache required). And I have a hard time figuring out why the vendors are pushing RAID5 solutions, if RAID1+0 means selling more disks to the customers :-). The answer, of course, is that they are making money on caches, not disks.

Technically speaking, RAID1+0 will always be better than RAID5, of course. Oh, they will try to compensate with caches and talk of RAID3 techniques and what have you. RAID1+0 is still superior to RAID5 in any techinal aspect.

It becomes really absurd when you look at the SAN offerings on the market. For instance, IBM's Shark only offers the customer the choice between JBOD (Just a Bunch Of Disks, ie., Non-RAID) and RAID5. IBM has a red book out regarding this and on page 127 out of 228 or so you can read the headline: "JBOD or RAID5?" and that's when it dawns on you that Shark (which is very expensive) cannot under any circumstances be configured for anything else than RAID5 or non-RAID. Workaround: Place a file system on top that at least can be striped (Veritas, for instance).

EMC has a standard offering where they'll suggest RAID-S (S looks a lot like 5, doesn't it?) and the standard answer if write performance is not good enough is: "Add more cache". Well, we had a customer who reached 32 GB of cache (not MB, mind you, but GB) and write performance was still bad (of course) for restores and recovery operations and file copying and all those things where a cache can never help you. Fortunately, EMC can be re-configured for RAID1+0, which the customer finally did, and all went well. They could then return the expensive cache and save some money :).

Same problem with HP (Hitachi) - they'll try to pursuade you to buy a very expensive RAID5 system. It's like trying to talk you into paying a lot of money for a WWII Spitfire, claiming that the avionics have been upgraded a great deal and that for the general user, this is much better than todays aircraft :-))).

We have lots of horror stories like this regarding RAID5. Of course it's good enough in a lot of situations. But you should know the reason why it's good enough. And the moment you have to restore or recover anything, you will discover the true price (factor 4, usually) of RAID5, namely the write penalty. No amount of cache can help you in those situations.

Christopher Spence wrote:

> Static data raid 5 is a very good option, it has great read performance and
> very inexpensive.
>
> "Walking on water and developing software from a specification are easy if
> both are frozen."
>
> Christopher R. Spence
> Oracle DBA
> Fuelspot
>
> -----Original Message-----
> Sent: Friday, June 08, 2001 6:20 PM
> To: Multiple recipients of list ORACLE-L
>
> My apologies, I should've been much more explicit... This is for a specific
> tablespace, with VERY static data...
>
> > Size of data, size of stripe size/width are very important in detirmining
> > how many spindles to use and if they will be effective. Using a
> write-back
> > caching controller (and not saturating it's cache) will generally write
> out
> > data trying to take advantage of the full stripe width. Reads are
> effected
> > in this manor as well.
>
> Yeah...I'm thinking 80/20 Read/Write for Controller cache, but again, this
> is not the puzzle
>
> Case: one tablespace (regardless of how many datafiles) for data, one tbs
> for indexes. 9 hard drives to deal with, with RAID 5 as level of choice.
> Should DATA reside on 6-drive volume and indexes on separate 3-drive volume,
> or should these two tbs live on same physical R5 volume?
>
> Gary
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Gary Weber
> INET: gweber_at_cji.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Christopher Spence
> INET: cspence_at_FuelSpot.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

--
Venlig hilsen

Mogens Nørgaard

Technical Director
Miracle A/S, Denmark
Web: http://MiracleAS.dk
Mobile: +45 2527 7100


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mogens =?iso-8859-1?Q?N=F8rgaard?=
  INET: mno_at_MiracleAS.dk

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).