Re: Subject: RE: ASM - number of LUNS rule of thumb

From: Jeremy Schneider <>
Date: Thu, 19 Aug 2010 10:53:19 -0500
Message-ID: <>

IMHO, the big question revolves around capacity management: what if you need to expand an existing diskgroup? Generally I've seen two strategies:
  1. Storage-based capacity management.

When possible, use a single LUN per diskgroup. (More only if exceeding ASM limitations - but really try to avoid this.) The storage admin - who knows a lot about this sort of thing - can be responsible for keeping a balanced configuration. Last time I was involved in setting a large-scale strategy for ASM was about 1.5 years ago. At that time, during my conversations with storage guys, it seemed that their storage systems really didn't handle LUN expansion very well for heavy workloads and resulted in data being a bit unevenly spread (and thus more potential hotspots). But we used this strategy at a smaller company I worked with; it works quite nicely for smaller environments that aren't very I/O intensive because it's very simple and easy to manage.

One note... there might be some snags with partition tables on Linux and hot resizing. The 11.2 docs claim that ASM will only detect partitions. ASMlib might negate that. Test first. :) I think that this is really a great option for small and mid-size environments.

2) VolumeManager-based capacity management.

For very large/intensive environments I think this is the preferred approach. Historically there was an OS-based dynamic volume manager - but it's really best NOT to layer ASM on top of these. (I've had a heck of a time convincing OS teams at large orgs about this!!) I think I remember some places in the Oracle docs that reinforce this recommendation too. ASM *is* a volume manager, best not to layer two volume managers on top of each other. Makes troubleshooting a bear.

With VolMgr-based capacity management, you choose one or several "standard" storage building-block configurations. For example, 50G "type A" LUNs (where "type A" refers to a specific underlying disk type). The storage guy only gives you storage in 50G chunks. If you want a 2TB volume then you request 40 of them. The policy says that you can't mix underlying storage types in a single volume/DiskGroup. At one company I've worked with, they had gold, silver and bronze storage with different chargeback rates. Clever naming scheme I think - and helped app teams understand what they were requesting. :)

But for VolumeManager-based capacity management, you need a much better grasp of your requirements so you can properly architect the building-block configuration. There isn't one correct answer.

As far as underlying storage config -- I am a proponent of the BAARF initiative, but otherwise I think you can work with the storage team and let them be the experts. Make sure they know your stripe size. (Oracle defaults to 1MB but explicitly recommends a 4MB stripe size in the 11.2 docs! And you can go bigger for DWs.)

Hope this helps a little,

Jeremy Schneider wrote:
> Sorry for the late response...
> This is not true. All LUNs do not have to be the same size in ASM.
> However, it is a best practice (and I have recommended it to people
> before). Mainly because it's quite easy to mess things up with ASM and
> storage if everything isn't the same in a diskgroup.
> But the actual important thing is not size - it's that the underlying
> storage is balanced. ASM stripes based on capacity. If two LUNS are
> the same size but one uses 7200 rpm drives and the other uses 15000 rpm
> drives, then this can cause difficult-do-diagnose performance oddities.
> (Not to mention different RAID levels!!) But if two LUNS are different
> sizes but both are RAID10 arrays of the exact same size/speed disks,
> then actually ASM will handle it quite well and the data will end up
> being spread evenly across all disk heads. There's storage network
> pipes to think about too, but that's not usually an issue because a
> single LUN typically is a small percentage of the traffic.
> -Jeremy
> David Robillard wrote:
>> Hello George,
>> One thing to keep in mind with ASM is that all LUNs in your disk
>> groups must be of equal size.
>> So if you use, say, 100 GB LUNs with ASM. Then when your database
>> needs more storage, you'll need to add a 100 GB LUN to your disk
>> group.
>> There was an interesting presentation on ASM on
>> Do a search for %ASM% in the documents
>> section of the site.
>> HTH,
>> David

+1 312-725-9249

Jeremy Schneider

Received on Thu Aug 19 2010 - 10:53:19 CDT

Original text of this message