Re: RAID5 question, take 2

Indeed, Paul. Very good points.

Gary - you're asking us to determine the number of bags we'll need at the supermarket without knowing what we're going to buy. If we had IO-stats for your datafiles/tablespaces, ie reads/writes and their size, and your availability requirements on the system, we could tell you more.

Paul Drake wrote:

> Gary,
>
> Here is where we have to know more details.
>
> a 9 drive array on a single channel sounds like your peak I/O rate for
> reads would be throttled by the controller channel speed. Now, if the
> SCSI interface is ultra 160/m, and the drive support a sustained rate of
> 20 MB/sec - you're not pinched. But if the RAID controller interface is
> FC - and only 100MB/sec - you're going to be seriously pinched during
> index range, fast full and full table scans - bulk reads.
>
> Are you using fine-grained striping - such that a FTS will be using the
> multiblock_read_count and will hit all 8 drives (net)?
> what's your:
> db_block_size
> multiblock_read_count
> OS I/O size
>
> If your OS I/O size is 128 KB
> and your db_block_size is 16 KB
> then a multiblock_read_count = 8
> and a stripe size of 128 KB - or 16 KB depth per stripe member.
> (as the parity drive is ignored)
> and each member in the stripe contributes one block in each read request
> for a FTS.
>
> SAME methodology would imply that your OS I/O size has been cranked up
> to 1 MB, and that your stripe size is also 1 MB. On a FC interface - the
> transfer speed for a 1 MB read would be 10 ms - on par with the average
> seek time.
> But SAME is not geared for RAID 5 - as RAID 5 supports having the drive
> heads out of sync to satisfy mutliple independent requests concurrently.
> SAME is geared more for RAID 0+1 - where the drive heads in an array
> move in unison - with all drives returning the results of one request at
> a time.
>
> What do you want to return for your read requests - (1 db_block,
> multiblock_read_count, 1 MB)?
> This will depend entirely on the access paths that are used in YOUR
> application.
>
> Basically - a 3 drive RAID 5 array is useless. Don't even consider it.
> Better off to have a single RAID 1 volume with a hot spare. If I were to
> break the 9 drives up (it would be as a RAID 0+1 of 4 drives each)
> - it would be as a 5 drive and 4 drive array (assuming that 2 channels
> are available).
>
> if most of the read requests have been driven by an index - and only one
> block is being requested - the 9 disk RAID 5 config is the way to go -
> as seek time will dominate transfer time.
>
> just my opinion.
>
> Paul
>
> Gary Weber wrote:
> >
> > The reply below was a great post! As were replies prior to it. But, none of
> > the replies were for the original question.
> >
> > The issue in hand is not which raid level to use or whether to use at all.
> >
> > The question is, and I promise this is the very last time I post it: given 9
> > hard drives dedicated for RAID5, should data reside on 6 drives via volume
> > group A and indexes on the other 3 drives via volume group B, or should data
> > and indexes be placed on all 9 drives via one volume group? The data is
> > absolutely static.
> >
> > Gary
> >
> > ----- Original Message -----
> > To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> > Sent: Sunday, June 10, 2001 7:15 PM
> >
> > > 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
> >
> > --
> > 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: Paul Drake
> INET: paled_at_home.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).