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: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
