RE: ASM LUN sizes and number of disks

Greg hit the nail on the head, but I feel a need to set the nail beneath the surface of the wood.

If you really DO have 6 disks currently, you'll be reducing total available throughput by a factor of 3 (or maybe a little less if the new disks are faster per spindle than the old.) Sometimes folks mix up talking about LUNs and disks, and the actual LUNs are only pieces of the same disk presented as if they are multiple disks.

I might quibble just a tad about "buys you zero." I think at the margin it actually buys you a little bit less than zero (unless you are in one of those configurations that allocates more i/o queuing threads if you have more mount points.) If I recall correctly Netapps filers have a component of performance like that.

In general, don't lie to ASM. If what you really have is two disks externally duplexed, give ASM a single LUN. Then it is clear to everyone that having multiple copies of control files on a disk_group built on that LUN is not the same as having them elsewhere, and all the silly things that result from presenting pieces of disks through a veil such that the consumer of storage is not immediately aware that the same unit of IOPS and I/O scan rates is being used.

It can also lead to the hilarity that results when folks don't want to have different disk sizes in a disk group, so they cut up the big new disk into pieces to add to the disk group. Then of course ASM will "balance" by size and end up putting twice as much data on the physical drive that is presented as two pieces even though it likely is just bigger, not more performant. Let me be clear, that is not a criticism of ASM but rather a criticism of lying to ASM.

ASM will tolerate plaid striping, hiding of the physical components, and all that as reasonably as should be expected with relatively little degradation.

But I believe the prime things you want to understand are:

Don't mix disks of different speeds in the same disk group. Don't try to exceed 2T for a single file on a 512 byte sector underlying disk.
Don't put non-ASM loads on the physical drives given to ASM. (You can partition such a disk to avoid use of part of the disk and match sizes with other disks in the disk group if you like to, and can even use the "excess" to contain relatively "cold" storage as long as you understand that i/o to that disk when you need ASM throughput will be degrade performance. And of course do not regard the "excess" as a backup for anything even partly resident on the same physical platter.)

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Greg Rahn
Sent: Monday, November 10, 2008 5:17 PM
To: hrishys_at_yahoo.co.uk
Cc: finn.oracledba_at_gmail.com; oracle-l_at_freelists.org Subject: Re: ASM LUN sizes and number of disks

On Mon, Nov 10, 2008 at 1:19 AM, hrishy <hrishys_at_yahoo.co.uk> wrote:
> I am still confused (although i do agree with ideas of Greg)
> Is there a paper which describes whats the ideal combination of disks and
sik sizes for ASM.

There are many resources here:
http://www.oracle.com/technology/products/database/asm/index.html

> I am using external redundancy should i still be worried about having only
2 disks ?

If you only have 2 disks, the only external redundancy you can have is to mirror them, then they would appear to the host as a single LUN. Sure, you could partition the disks and present that as multiple LUNs but that buys you zero.

> I am planning to add 2 2000Gb disks and then simulatenously drop the
> 6 50Gb disks so rebalance is a single operation

Space is cheap, but spindles are expensive. IOPS and I/O scan rates are proportional to the number of spindles. In your case, by moving from 6 to 2 drives you are cutting down the IOPS and I/O scan rates by a factor of 3, so you are reducing your drive performance in order to add capacity. Be careful...

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




--
http://www.freelists.org/webpage/oracle-l