Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: XP256 Disk Striping for an Oracle 8.1.7 DataWarehouse

Re: XP256 Disk Striping for an Oracle 8.1.7 DataWarehouse

From: Steve Holdoway <steve_at_itemfront.ltd.uk>
Date: Tue, 24 Jul 2001 19:06:50 +0200
Message-ID: <mt7rltonoeu1qdd348fi0mi92puigd1hr5@4ax.com>

Sorry, finger slipped. This is a slightly better attempt at answering!

There is a max number of physical extents per 'disk' in a volume group. When you're up in the hundreds of GB range, then you need to look at this value to see if you can actually create the volumes the size you want given a smaller extent size. This may also directly affect the VG size, and hence the number you wish to create. max_pe can be set to 64k-1 as a maximum, and the pe_size can be between 1MB and 256MB, giving a VG size of between 64GB and 16TB per 'disk'. So I'd take care when configuring the XP256.

On top of the hardware raid, you're then adding another level when creating the lv's. Is it not possible to sort out all of the striping at the hardware level, and not duplicate it at the OS level as well? You're not striping over physical disks any more, so the term 'striping' takes on a much more complex meaning!

I'm not too familiar with the XP256, but I think it has a large IO buffer cache through which the disks are accessed. If so, striping may actually slow down the performance of the array, by confusing any read ahead algorithms that may be in place in the array. I expect that you'll only find the optimum setup for your system by trial and error ( although I expect that it won't include raid 5! ).

I hope this makes sense - I'm going through a stage of having to unlearn, or at least question, loads of things that I'd thought to be set in stone - like regularly accessed data should be kept in the middle of the disk for faster access! ok I'm exaggerating, but it's very difficult to model the path that data takes from disk platter to server memory, when there's a cache on the disk, hardware raid, then a large buffer cache on the array, separating the disks from the servers, then striping gets involved...

Time for valium, I think!

Steve

On Mon, 23 Jul 2001 23:47:57 GMT, George Petrides <george_at_parallon.com> wrote:

>When you say 'stripe size' do you mean LVM striping? I played around with
>stripe sizes before and I have not seen much of a difference to be honest
>with you. As far as one large group, I would suggest breaking it to few
>groups for organizational sake. Four volume groups sounds like a good
>number but it's really up to the admin, just don't make too many small
>ones cause you loose flexibility.
>Thanks,
>George
>
>Tom Lewis wrote:
>
>> I have a 400GB Oracle 8.1.7 data warehouse deployed onto a XP256. The
>> warehouse often needs to full table scan tables of c50GB and uses
>> parallel execution to achieve this. The database is using 8K blocks
>> and the DB_FILE_MULTIBLOCK_READ_COUNT is set to 16.
>>
>> The XP256 has been configured with RAID 5 and a stripe size of 256K.
>> Its 36 disks have been divided into 8 logical volumes of 4-6 disks
>> each with different tables or indexes assigned to each logical volume
>> to avoid contention.
>>
>> I really need some help on two fronts.
>>
>> What is the optimal relationship between the DB block size and the
>> stripe size. Currently, I assume that the database will read 32 blocks
>> off disk 1 and then 32 off disk 2 etc. etc. That does not sound very
>> parallel to me. Should the stripe size be smaller?
>>
>> Secondly, is it necessary to divide the XP256 into different volumes
>> for different purposes or is a larger single volume a better approach?
>>
>> Many thanks in advance
>>
>> Tom
  Received on Tue Jul 24 2001 - 12:06:50 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US