RE: ASM LUN sizes and number of disks

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <nigel.cl.thomas@xxxxxxxxxxxxxx>, "'Oracle-L Freelists'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Sat, 15 Nov 2008 14:38:26 -0500

That's right, and there is a third option, which is to have more disk
groups, so that each disk group is composed of homogeneous disks.

 

And thanks for clarifying that Nigel.

 

Mark

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Nigel Thomas
Sent: Wednesday, November 12, 2008 7:22 AM
To: mwf@xxxxxxxx; Oracle-L Freelists
Subject: Re: ASM LUN sizes and number of disks

 

Mark mentioned: "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"

 

So there are valid options, depending on your requirements: 

If you want to spread data across a heterogeneous bunch of discs, and
read/write performance is not your primary concern then you should probably
carve up all your discs into LUNs of the same size. ASM will then balance
data across all of the LUNS - so when your 2Tb disc is 70% full, so will be
your 100Gb disc.

 

If you want optimal read/write performance and you don't mind wasting some
space on the larger discs, then follow Marks suggestion of one LUN per
physical spindle. Your drives will fill up to the size of the smallest disc
(if I understand correctly).

 

If you want the best combination - just use the same size (and performance)
discs (and have 1 LUN per physical disc). Now you make a tradeoff to make
between the size, iops, latency and cost of the discs.

 

Of course, in real life you may wish break down the data in your application
into different categories, for some of which (eg latest transactions) r/w
performance is critical, and for others (eg last year's warehouse stock
movements) optimal space usage is more important.

 

Regards Nigel

 

Other related posts: