Re: ASM on SAN

I'm a fan of multiple LUNs, not a single (or two) unless its a relatively tiny/small database (<500GB). The main reasons for this are growth and flexibility. If you design the storage layout using say 2+2 RAID-10 LUNs then you can simply add more and let ASM rebalance. If you choose a very large LUN size, then you should really add that much again (ASM recommendation/best practice) which means you double your space and then have to rebalance 50% of your data. The other thing is that with there are multiple LUNs you tend to get a better distribution of work across as many resources as possible. This plays into things like SCSI queues, multi-pathing, etc.

The other thing is that most of the storage engineers (people that design this stuff) or performance engineers (people that perf test it) will tell you there is a sweet spot for the LUN size and characteristics. This varies from array to array, but I would seek out this information. It usually has to do with things like which drives are on what controllers and primary vs secondary IO paths, etc.

Either way, I would recommend letting the array do the RAID (external redundancy) but would recommend that the hardware RAID stripe size be at least 1MB or larger, as this is the default ASM AU size.

On Sun, Feb 21, 2010 at 11:16 AM, Chen Shapira <cshapi_at_gmail.com> wrote:
> I'm preparing to install ASM using our EVA storage and I'm trying to
> decide how many volumes to request from my storage manager.
>
> There are two configurations we consider:
> 1) Ask for two volumes - one for data files, the other for flashback,
> archive logs, backups, etc. Then run ASM with external redundancy and
> external striping. Let EVA do the RAID thing for us.
> 2) Ask for multiple data volumes and multiple backup volumes.
> Configure ASM to do its own striping. Since EVA will do its own
> stripe+mirror thing, we'll have double striping.

-- 
Regards,
Greg Rahn
http://structureddata.org
--
http://www.freelists.org/webpage/oracle-l