Re: To RAID or not to RAID (...or how to RAID)

Rick Denoire <100.17706_at_germanynet.de> wrote:

> Please correct me, but to my understanding, Raid systems loose their
> advantage of parallelizing the mechanical side of things (i.e.,
> rotation of spindles and movement of heads) if I/O is going to be of
> random type; that is, Raid is more appropriate for sequencial
> operations rather than for one-block-access.

That sounds like striping (one possible componoent of Raid) as I know it.

> So by separating tables
> and indexes into two logical devices consisting of independent
> harddisks, head jumps can occur in parallel

I don't know what you mean here. You mean they can occur independently? To me, in that sentence, parallel would mean 'concurrently and coordinately', but I don't think that way makes much sense.

> and are reduced for every
> logical device, since Oracle demands access to indexes and tables
> (except for table scans, of course - but these should be avoided in my
> experience).

Sometimes you do table scans, sometimes you do index scans, sometimes you do random access. By separating the disk into 6+4, you deprive your indices of 6 spindles during an index scan, and deprive your table of 4 spindles during a table scan. If you rarely do scans, but only random access, then it probably doesn't matter much--either way.

> Another question concerns the stripe size and arises when considering
> what happens when the DB tables are tuned to use indexes and most of
> I/O are one block operations. If the minimal data chunk that can be
> read at a time from one spindle is larger than one Oracle block, then
> no parallelism will be possible.

Nor would it be beneficial (WRT striping).

> Every block will be read entirely
> from just one harddisk, exactly the way that they are read when using
> single disks without any Raid. Correct me at this point but does not
> that mean that the stripe width (over all harddisks) should be as
> close as possible to one Oracle block?

Without studying the matter, I'd say not.

> In that case, reading one block
> would force using all disks. For example, with a Raid of 4 disks and
> an Oracle block size of 8K, the stripe size on every disk should be
> 2K. This is unusual small so I need your advise here.

If you are reading only 8k, then latency is going to be more time consuming than actually reading the data. So now rather than taking at least as long as some random amount of time, the read takes at least as long as *the longest of four* different random times. I'd much rather roll one dye, than to roll 4 dice and take the worst value of the four.

As you said yourself earlier, Raid (striping) doesn't work well on random access, so why force random access to participate in striping?

> The third question - you would guess that - refers to the optimal size
> of the Oracle parameter db_multiblock_read_count in a Raid
> environment. Since this parameter is global for the DB, it can't be
> tuned to all devices at a time. For example, a Raid of 8 disks would
> be best suited with a db_multiblock_read_count=64 (assuming a
> blocksize of 8K)

Under what stripe size is 64 supposed to be optimal?

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
                    Usenet Newsgroup Service