Re: Setting up storage Array for ASM

From: Leyi Zhang (Kamus) <"Leyi>
Date: Tue, 26 Apr 2011 11:08:39 +0800
Message-ID: <BANLkTikgcbVyPfyvN88Q-LvaCFxRUzitwg_at_mail.gmail.com>



I would also like to use 2*500M LUN for datadg instead of 1*1T LUN, since it's not so critical, I didn't give this suggestion in my last reply.
My thought is: if your storage box has 2 controller (A controller and B controller), you can create 2 LUNs and set each using the separate controller as preferential device, eg. LUN1 prefer using A controller and LUN2 prefer B.
--
Kamus <kamusis_at_gmail.com>

Visit my blog for more : http://www.dbform.com
Join ACOUG: http://www.acoug.org



On Tue, Apr 26, 2011 at 7:42 AM, Steven Andrew <postora_at_gmail.com> wrote:

> On Fri, Apr 22, 2011 at 4:53 AM, David Robillard <david.robillard_at_gmail.com>
> wrote:
>>
>> With that in mind, you might want to change the 2 x 1 TB LUNs for 4 x
>> 512 GB LUNs. But keep in mind that if you need to add more disk space
>> to either disk groups, you will need a 512 GB LUN which is relatively
>> big. That is to satisfy the ASM data distribution and balance
>> operation as the fine manual says: Oracle ASM data distribution
>> policy is capacity-based. Ensure that Oracle ASM disks in a disk group
>> have the same capacity to maintain balance. In other words, use LUNs
>> of the same size in the same disk group.
>>
>
> Hi David,
> Thanks for the detailed mail. One thing I tend to disagree is minimum 4 LUNs
> per diskgroup recommendation. Isn't creating smaller LUNs, increases the
> LUNs maintenance in the DG like having smaller datafiles for tablespaces. At
> least that was the theory i had come up with fewer bigger LUNs within DG. As
> all LUNs will be coming off of same RAID set, does it really matter having
> smaller LUNs? I understand to increase the DG, i would need another TB, but
> if database is NOT going grow beyond allocated space, it shouldn't be a
> problem right.
> Thanks,
> Steven.
>
-- http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 25 2011 - 22:08:39 CDT

Original text of this message