Oracle, Technical

Oracle ASM Stripe Size

Right now I’m working on some internal documentation and referencing Oracle 11g’s Storage Administrators Guide (ASM manual). And I think there’s a bit of a contradiction here about the stripe size. ASM uses a variable “data extent” size when allocating space for files (like any sane filesystem) – the first 20000 data extents are equal to the diskgroup allocation unit (AU), the next 20000 are AU*8, etc. But it’s a little unclear to me how the stripe size is determined. Seems to me that you’d stripe “data extents” rather than allocation units and I think I’ve even heard before that “extents are mirrored [and presumably striped]” in ASM. In fact the illustration in the manual shows the stripes in exactly that manner:

ASM Extents

ASM Extents

However the manual states that the opposite is true – striping based on AU instead of data extent – in two different places on that page. First, just before the illustration:

The ASM coarse striping is always equal to the disk group AU size, but fine striping size always remains 128KB in any configuration (not shown in the figure). The AU size is determined at creation time with the allocation unit size (AU_SIZE) disk group attribute. The values can be 1, 2, 4, 8, 16, 32, and 64 MB.

And again right after it:

To stripe data, ASM separates files into stripes and spreads data evenly across all of the disks in a disk group. The stripes are equal in size to the effective AU. The coarse-grained stripe size is always equal to the AU size. The fine-grained stripe size always equals 128 KB; this provides lower I/O latency for small I/O operations such as redo log writes.

As far as I can tell, it seems to be a contradiction in the manual. I commented on the documentation page and I’ve opened an SR; I’ll post an update when I get a reply.

Update 4:45pm:

The SR got answered very quickly (less than an hour) – and said that striping is based on the data extent size. The usage of the term “allocation unit” was what I found confusing (even in the SR resolution)… but at least we have an answer. :)

Suppose you have a diskgroup with 1MB AU size. After a particular file has 20000 extents, the allocation unit for that file becomes 8MB.

allocation unit = extent size
40000>extent>20000 => FILE_AU=DISKGROUP_AU*8.

Here’s the definitive quote from the SR: “[After 20000 extents] the 8meg AU will be striped, with the first 8meg AU on disk one, the second 8meg AU on disk 2 and so on.”

This would apply for both striping and mirroring. My gut feeling was right; I was just a bit confused by the definitions of extents and allocation units in the manual (which are incorrect).


About Jeremy

Doing stuff with Oracle Database, Performance, Clusters, Linux. about.me/jeremy_schneider


4 thoughts on “Oracle ASM Stripe Size

  1. "striping is based on the data extent size. The usage of the term “allocation unit” was what I found confusing (even in the SR resolution)…"

    I agree it is confusing. But I think it might have to do with the behavior in 10g where extent and AU are always the same size thus two words are used interchangeably. However, this is “not” always true in 11g.

    allocation unit = extent size
    40000>extent>20000 => FILE_AU=DISKGROUP_AU*8.

    I assume you meant –

    Number of extents  Extent Size
    <20,000           AU
    ≥20,000 and <40,000  AU * 8
    ≥40,000          AU * 64


    So the “FILE_AU” is actually the “extent”, and “DISKGROUP_AU” is the “AU” we always refer to.

    Based on the statement in metalink note 465039.1 shown below, above statement makes sense.

    “Also, note that in ASM the space is managed logically using Allocation Units (AU) at the disk level and Extents at the file level

    “Suppose you have a diskgroup with 1MB AU size. After a particular file has 20000 extents, the allocation unit for that file becomes 8MB.”

    When first read this, my first impression was “after 2000 extents, the AU (implying DISKGROUP_AU) becomes 8MB in size”, which I don’t think that is the case. After 20000 extents, the extend size will become 8MB because the extent size is now 8 times of the AU size. The AU size still remains at 1MB. The word “allocation unit for that file” threw me off. However, if I replace it with FILE_AU (which is extent), it makes more sense. Is this what it meant here?

    Great investigation.



    Posted by Ittichai | December 10, 2008, 11:44 pm
  2. Wow – reading the 10gR2 ASM manual actually helps a lot. I think you’re exactly right that the confusing terminology in 11g is a result of the fact that 10g didn’t have multiple extent sizes.

    The coarse-grained stripe size is always equal to the AU size.

    The course-grained stripe size is the extent size. The 11g manuals seem to refer to both a DISKGROUP AU (au_size property) and a FILE AU (extent). The metalink article you quoted seems to fit with this terminology too.

    It’s a mess; I hope they clean it up in 11g release 2 (whenever that actually gets released).

    Posted by Jeremy | December 11, 2008, 12:33 am
  3. Sorry for being late, but I’m just catching up on my feed reader now.

    You’d probably benefit from reading the Oracle Press book on ASM written by Murali, Nitin, and Rich. I’ve just about finished it and found it an excellent resource for technical information. It covers extent allocation, striping, and more with a good amount of detail. It also does a great job of easing into those deep details, so it’s also well-suited for those new to ASM. At about 280 pages, it’s also a pretty quick read (I am a slow reader, so that’s important to me), so you could probably knock it out in a few days.

    Posted by Dan Norris | January 15, 2009, 2:06 pm
  4. sorry for being (very) late.

    i’m in position now talking between DBA’s and SAN admins about the 128K small stripe size. Do you know if metadata is in the declared strip sizes or if it outside of it? If it is outside of it, how much metadata is there per a given extent size (128K in this example)?

    Posted by bruce | May 21, 2010, 1:59 pm


(a) We are currently looking for consulting and/or contracting work in the USA around the oracle database ecosystem.

Contact Jeremy at 312-725-9249 or schneider @ ardentperf.com


oaktable ocmaceracattack
%d bloggers like this: