celerra fc oracle meta luns

Hi,

as you're using the FC capability of that box, and as such by passing the NAS head altogether, you might get better results posting this question in the Clariion forum.  I'm afraid I not much help with your question though.

Kevin,

Tks, I have taken your advice and posted the exact same query in the clariion forum. The additional information I provided was in responce to dynamox, as I am really looking from advice on the white paper as well as real work experience to back it up.

our Oracle boxes are connected to DMX but the idea is the same, we do not resize already presented LUNs, we provision new LUNs.  Once you add them into ASM it will automatically "rebalance" the ASM group, plus you get more I/O queues in the OS.

The reason I am asking is there were italics in the doc where it said

Answers on a postcard to this forum

related question to this. Oracle documentation says optimal lun numbers to be presented to an ASM group is between 4 and 8. Have you experience situation where you are exceeding 8 luns in an ASM group. If so, have your DBA's seen performance degradation or do you keep adding luns. The reason we were looking at metaluns in the first place was in part because of this as we would be able to asign a static number of metaluns and worry about growing/rebalancing the metaluns at the clariion level and let ASM be oblivious to the rebalancing.

i talked to our DBAs so what happens is they request storage in exact increments, for example ASM disk group is built out of 17G LUNs. If they need more storage we provision more 17G LUNs. He said they had issues if we present LUNs that are different in size. Once LUNs get added to ASM disk group they automatically begin "rebalancing" process ( not sure if that's a policy that gets set on ASM disk group or it does it be default). If you want to remove a LUN from ASM disk group, you need to make sure other LUNs in the group have enough capacity. Once you specify to remove the LUN, ASM will move the extends from that LUN onto other available LUNs in the group, once completed you can reclaim LUN from the OS. (nice way to migrate to new storage array online).

ok,

so does the  4 - 8 lun limit occur for any of the ASM disk groups or have LUNS been added in 17G increments irrespective of how many LUNS are already in group ?

My understanding is the rebalancing process is manually kicked off as it impacts on DB performance and is recommended by Oracle to occur during a quiet DB time.

So I guess, meta LUNS does not occur at your site with regard to Oracle usage.

If so, then I guess I should try to get EMC to decypher their white paper !

minimum for ASM disk group is 2 LUNs, we have ASM disk group with 32 x 17G LUNs. DBA said ASM will take as many LUNs as underlying OS can support. You know how EMC white papers say to not triple stripe so if you use striped MetaLUNs that's striping twice already and then you stripe it again in ASM. By not creating MetaLUNs you could create regular flare LUNs and place some on SPA and some on SPB so you get to load balance it at SP level. At my site all Oracle boxes are connected to DMX/Vmax and our small device size is 17G so we present regular 17G devices, not meta's.  Let us know what you hear from EMC/Oracle experts.

ok I had a chat session and after some initial confusion as EMC Confidential was written on the documentation and I am convinced the agent though I was a competitor trying to be smart I was told that a a MetaLUN should not be used and rather a basic LUN. I suspect if I drilled down into the why's that triple striping is the reasoning, but the reasoning was left out and I was given a straight this is what we recommend full stop.