RE: To ASM or Not to ASM

  • From: "Murching, Bob" <bob_murching@xxxxxxxxx>
  • To: "'Amihay Gonen'" <AmihayG@xxxxxxxxx>, "'oracle-l'" <Oracle-L@xxxxxxxxxxxxx>
  • Date: Wed, 13 Jul 2005 08:58:53 -0400

Probably should cc: this on oracle-l.
 
Regarding performance, several storage vendors (EMC and NetApp come to mind)
claim optimal performance by letting the storage array stripe physical
spindles inside the array, splitting this striped physical volume into
multiple logical volumes, presenting them to the host as multiple LUNs and
letting ASM stripe (again) over those logical volumes... hence plaiding.  We
never got around to testing whether this actually improves performance,
instead opting to let ASM do its extent-level striping across separate
RAID10 groups used as separate ASM disks.  The performance has been good
(actually, it's been terrific) but if I could do it all over again, I'd
probably try a "plaiding" approach - I can see how this would allow ASM +
SAN to improve performance.
 
Official recommendations are on OTN in the "ASM" area - EMC and NetApp have
published some whitepapers.  In practice, I have found that we quickly can
glean more information on our own than from vendor contacts.
 
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.

  _____  

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 10.1.0.4 on Solaris
64-bit
- the disk group management really does work
- there is almost no tuning necessary - it works well "out of box"
- 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 database.
 
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 .
 
Advantanges:
1. Simply configuration and maintenance. (same layout ,with regard to O/S
type . The only change is the numbers of disk per disk group)
2. Reduce extra level of LVM (reduce price , same vendor in all the stack ).
3. Performance (raw device access , striping in extent level )
 
disadvantages:
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
DBA

 

Other related posts: