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