RE: To ASM or Not to ASM

  • From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
  • To: "oracle-l" <Oracle-L@xxxxxxxxxxxxx>
  • Date: Wed, 13 Jul 2005 10:52:16 -0700

        We have one fairly mission critical DB running on ASM, size
about 200GB (not too big) and we need to be able to hit somewhere in the
neighborhood of about 5K IOPS of mixed read/write (including redo),
which we're able to do quite easily with ASM managing, I think, 26 x 15K
disks.  I've been pretty pleased.

~192 Iops per spindle is awefully good, but that would likely be more
a reflection of the fact that you are only using some ~33GB per spindle
than an attribution to ASM... in fact, ASM does not change the IO
code path at all..the Oracle skgf* routines are what they are. Once
and ASM file is open, shadow and foreground processes simply position
and read or write.... ASM doesn't change that

Kevin Closson
Chief Architect, Database Solutions


        From: Amihay Gonen [mailto:AmihayG@xxxxxxxxx] 
        Sent: Tuesday, July 12, 2005 3:57 PM
        To: Murching, Bob
        Subject: RE: To ASM or Not to ASM
        Hi bob , thanks for the feedback.
        Are the any official recommendations from EMC/NetAPP on using
ASM ?  Do you have contact information that I can talk with ?
        What do you mean mulipathing across LUNS ? can you give an
example ? 
        What are the size and I/O requirements from the databases that
you have placed on the ASM ? 

        From: Murching, Bob [mailto:bob_murching@xxxxxxxxx]
        Sent: Tue 7/12/2005 7:03 PM
        To: Amihay Gonen
        Subject: RE: To ASM or Not to ASM
        Some quick thoughts -
        We're using ASM in a limited but production capacity.  Some
observations -
        - it has proven to be extremely stable, at least as of
on Solaris 64-bit
        - the disk group management really does work
        - there is almost no tuning necessary - it works well "out of
        - lack of multipathing across LUNs is kind of frustrating.
Well, very frustrating.
        - difficult to move files in and out of ASM volumes.  Difficult
to "script" although this has been addressed a bit in R2
        - performance monitoring interfaces are weak / clumsy / generate
questionable data
        - everyone (EMC, NetApp, etc.) seems to recommend using ASM
stripping on top of SAN/NAS striping (i.e. "plaid") as a best
practice... I find this interesting.
        - oh... fast, clustered storage for RAC.  always nice to have.
        I'd appreciate reading any thoughts or additional feedback you
receive as well... we're in the same boat, but I chose to roll out ASM
for some instances just to "kick the tires"


        From: Amihay Gonen [mailto:AmihayG@xxxxxxxxx] 
        Sent: Tuesday, July 12, 2005 11:53 AM
        To: oracle-l@xxxxxxxxxxxxx
        Subject: Q:To ASM or Not to ASM
        I've some questions on ASM (automatic storage management )
        I've read a lot of materials on this issue , I think ASM is a
good concept in simplify the installation & maintenance of oracle
        I work in R&D in my organization , and we need to decided if to
cooperate ASM instead of some other LVM.
        I build a small list of advantanges and disadvantages on ASM ,
and some questions . I would like to hear you comments .
        1. Simply configuration and maintenance. (same layout ,with
regard to O/S type . The only change is the numbers of disk per disk
        2. Reduce extra level of LVM (reduce price , same vendor in all
the stack ).
        3. Performance (raw device access , striping in extent level )
        1. New technology . Not wide speared , most IT doesn't have
enough knowledge in this area. 
        2. Backup & recovery must be done using RMAN .
        3. Single point of failure - If ASM instance is down ( , I'm not
sure about this point).
        My questions are :
        1. Do you think that ASM will be acceptable next year as LVM
solution for oracle database in big companies ?
        2. Do you think that ASM can be fine tuned as you can tune in a
file base level installation ? 

        Amihay Gonen


Other related posts: