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

Rick Denoire <100.17706_at_germanynet.de> wrote:
>
> >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.
>
> Let's take the case of an index scan. While reading indexes
> sequentially, Oracle would go for the corresponding records in the
> tables.

I think indices are usually read sequentially only if the query can be resolved soley with the index, not needing to reference the table blocks. If you are doing a range scan, you have to follow the B*tree structure, which is not sequential. A full index scan which needs to look up many table blocks should probably be done as a full table scan instead.

> Wouldn't that be a case where parallel operations would be
> possible if the physical design mentioned above was in place?
> The device doing sequential access to indexes would not be disturbed
> by random accesses to tables.

Perhaps. But if the system has a fair load, I think unrelated activity is going to disturb the sequential access to the indexes enough that self-disturbing won't matter much. Of course, your server may not have so much contention.

> >> 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).
>
> What I meant was that if the product of (Oracle Block size x
> db_multiblock_read_count) is in N stripes of a Raid consisting of N
> disks, then any operation would involve all disks,

Any *sequential* operation would involve all disks for that case. Random ones wouldn't. But if you had it tuned so most access was random, it won't hit all spindles for one IO and wouldn't be good if it did hit them all.

> that is, parallel
> operations of disks. In order to achieve that, one has to make stripe
> size quite small,

Or db_multiblock_read_count quite large.

> and this is contradictory to general experience of
> people choosing rather big stripe sizes.

Yes, I think you're right. With the setting of stripes (1Meg) and multiblock_read_count (<=128 with 8K block) that I see bandied about most often, it doesn't seem like striping actually does anything.

>
> Anyway, I didn't understand your short answer.

Parallellism isn't possible on the block level without making absurdly low stripe size, and if did do it it wouldn't be beneficial. But, striping is only part of RAID, there's also mirroring, which does help single block reads.

> >> 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?
>
> Whatever the optimal size is, my question regards to the immanent
> difficulty in trying to setup a value that is suitable for different
> hardisk systems.

Well, you could very the stripe size from RAID to RAID so that the stripe size* stripe width=oracle block* oracle multi_block_read_count.

Or have all stripes sizes the same. I doubt it is exteremly sensitive, so just pick a middleish number for muliblock read. If one read covers 4 of the 6 spindles in the big raid, how much difference would that make versus hitting all 6? Or, if it hit two of the 4 spindles twice in the smaller raid, how bad would that be? Afterall, the second time it hits the spindle everything should be already lined up for it.

Xho

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