Re: Question on ASM LUN size and adding datafiles
- From: Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>
- To: jason arneil <jason.arneil@xxxxxxxxx>
- Date: Sun, 21 Nov 2010 11:44:35 -0600
Jason
Thanks for correcting me..I goofed. Here are few lines from note
460155.1. " ORA-15041 IN A DISKGROUP ALTHOUGH FREE_MB REPORTS SUFFICIENT
SPACE".
>> On the other hand, if ASM disks are not of the same size (e.g. disk 1 is
>> 10GB,
>> disk 2 is 50GB and disks 3-10 are 10GB), ASM allocator will place one extent
>> on
>> disk 1, five extents on disk 2, one extent on disk 3 and so on. This is to
>> ensure balanced disk utilization.
Error message in my client situation was that the client employs NORMAL
redundancy which means that ASM will try to allocate extents from at least
two disks running in to ORA-15041 error messages.
But, either way, I would still recommend only equal sized LUNs ( as you
also recommended).
Nuno
I see an email from you. My second comment was only about database level
autoextend, nothing to do with ASM.
Cheers
Riyaj Shamsudeen
On Sun, Nov 21, 2010 at 5:25 AM, jason arneil <jason.arneil@xxxxxxxxx>wrote:
> Hello,
>
> Just a point of clarification, though I don't disagree with your
> conclusions:
>
> " ASM will try to keep same number of extents in every LUN"
>
> I don't believe that to be true. ASM allocates extents to LUNS based on the
> policy of filling up each LUN to the equivalent amount. So if you have a LUN
> that is twice as large as another it should receive twice as many extents.
>
> You can check the number of Allocation Units both allocated and free in the
> luns of a diskgroup by using x$KFDAT.
> Check out metalink note 351117.1 for some useful diagnostic queries.
> That being said, I too have seen issues with having a diskgroup based on
> unequal sized LUNS whereby a LUN getting filed up will stop writing to the
> diskgroup even if the other LUNS have available space - avoid uneven sized
> LUNS it if you possibly can.
>
> Of course there is also the issue that a large sized LUN may not have any
> performance than a smaller sized LUN but will receive undergo I/O due to the
> allocation policy above.
>
> jason
>
> --
> http://blog.jarneil.co.uk
>
>
>
> On 20 November 2010 19:27, Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>wrote:
>
>> Kumar
>>
>> 1. That's right, don't mix lun sizes. Extents are moved from the
>> existing luns to the new new luns during rebalance operations. ASM will try
>> to keep same number of extents in every LUN. So, if you mix 90 GB and 60GB
>> luns, if you run out of space in 60GB luns ( even when there is free space
>> in 90GB luns! ) you can run in to free space errors. I just had a client
>> issue where the admins decreased new luns size to 50GB from 200GB original
>> LUN sizes causing ASM errors.
>>
>> 2. If you know how much you need, it is better to allocate ahead of
>> time. Autoextending has *some* amount of overhead (but not too much as long
>> as you keep meaningful extend size). Autoextend also updates the file
>> headers, and you can run in to concurrency related to issues in the file
>> header block if there are many processes constantly trying to extend the
>> files.
>>
>> Cheers
>>
>> Riyaj Shamsudeen
>> Principal DBA,
>> Ora!nternals - http://www.orainternals.com - Specialists in Performance,
>> Recovery and EBS11i
>> Blog: http://orainternals.wordpress.com
>> OakTable member http://www.oaktable.com
>> Co-author: "Expert Oracle practices: Oracle Database Administration from
>> the Oak Table" http://www.apress.com/book/view/9781430226680
>>
>>
>>
>> On Sat, Nov 20, 2010 at 12:25 PM, Taral Desai <taral.desai@xxxxxxxxx>wrote:
>>
>>> ASM
>>> ----
>>> The way it distribute data you might end up with error saying that there
>>> is no space on other disk to replicate data. I can't remember exact error.
>>> Other issue would be combination of different disksize like lets say 10gb (3
>>> disk group) you added 20 GB 4 th disk. in that you will not able to use more
>>> then 10g. That relate to same as first issue.
>>>
>>> Datafiles
>>> ----
>>> Test Your self. Oracle need to format block before it has to write to it
>>> so if it's done prior or latter i think doesn't make much difference in work
>>> wise. Only thing is while you are running your load process if it's taking
>>> to much resources then formatting make take bit time due to other latencies
>>> but that can be a not a major difference performance wise.
>>>
>>> I may be wrong so test it and see what happens.
>>>
>>>
>>> On Sat, Nov 20, 2010 at 10:19 AM, Kumar Madduri <ksmadduri@xxxxxxxxx>wrote:
>>>
>>>> Hello All:
>>>> ASM LUN Size question:
>>>> ----------------------------------
>>>> Are there any disadvantages (in terms of imbalance and consequent
>>>> performance impact) if you add different LUN sizes to the same disk group?
>>>> Storage administrator usually gives us 90GB LUN Sizes ; But if they
>>>> decide to give 60 GB LUN sizes and from a storage point of view, they dont
>>>> see a difference in giving us a 90 GB vs 60 GB LUN.
>>>> My understanding is that , once ASM rebalance is complete, there would
>>>> not be any performance issue or imbalance issue. Also, since LUNS are
>>>> logical units, I can still have different LUN sizes in the same diskgroup
>>>> and would be ok. Ideally it would be good to get the LUNS of same size. I
>>>> did read a few blogs where there were issues with different LUN Sizes but
>>>> that was more due to rebalance not happening to start with.
>>>> Can you correct my understanding if it is incorrect ?
>>>>
>>>> Adding datafiles
>>>> ----------------------
>>>> This is not related to the above clarification. If I am doing a major
>>>> application upgrade and I know couple of tablespaces are used extensively
>>>> in
>>>> the upgrade (I would be adding additional 200 GB of data as a result of
>>>> upgrade in to these two tablespaces), my understanding is that since I know
>>>> that this upgrade is going to take 200 GB of data, I would be better off in
>>>> creating datafiles for those tablespaces and allocate the space in one go
>>>> before the upgrade (like alter tablespace ttt add datafile 'xxxxx' size 8g
>>>> ) instead of alter tablespace tttt add datafile 'xxxxx size 32m
>>>> autoextend
>>>> on next 32m maxsize 8192m and let Oracle allocate extents as it needs
>>>> (even
>>>> though this is LMT, allocating extents in this manner may be less efficient
>>>> than in one go especially when we know the volume of data to be loaded).
>>>> Can
>>>> you please clarify?
>>>>
>>>> Thank you
>>>> Kumar
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Taral Desai
>>>
>>
>>
>
Other related posts:
