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

ctcgag_at_hotmail.com wrote:

>Rick Denoire <100.17706_at_germanynet.de> wrote:
 

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

By stating parallel I mean that operations can take place at the same time. One application would read indexes, another would deal with tables. But I agree that the main reason to separate indexes from tables in different tablespaces is not due to performance, but because administration is made easier.

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

>
>> 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, that is, parallel operations of disks. In order to achieve that, one has to make stripe size quite small, and this is contradictory to general experience of people choosing rather big stripe sizes.

Anyway, I didn't understand your short answer.

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

OK, here I see that you are right. Why should the system be forced to random read something by using 8 disks if it can do it as fast by using only one? Since in this case, the amount of data is so small, latency is a more important factor than the time actually spent by the read operation itself. Again, it is clear than stripes are best suited for sequential reading.

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

Bye
Rick Received on Sun Sep 15 2002 - 16:58:24 CDT