RE: RAID5 question, take 2

Mogens, the super-market analogy does not apply - this is for SQL Server database. I'm not sure how far I'll be able to tweak that rdbms, hence my question did not contain many details - it was simply a request for opinions.

Btw, to sum up current responses:
Option 1: split 9 drives to separate data/index I/O Option 2: stripe everything across 9 drives for better throughput.

So, methinks the Windoz admin is going to try both ways and monitor i/o...

Thanks to Paul, Jared, Christopher for great input,

Gary Weber
Senior DBA
Charles Jones, LLC
609-530-1144, ext 5529

-----Original Message-----
Nørgaard
Sent: Monday, June 11, 2001 3:15 AM
To: Multiple recipients of list ORACLE-L

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

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