Re: Question on ASM LUN size and adding datafiles
- From: Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>
- To: taral.desai@xxxxxxxxx
- Date: Sat, 20 Nov 2010 13:27:46 -0600
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:
