RE: To ASM or Not to ASM

From: Kevin Closson <kevinc_at_polyserve.com>
Date: Wed, 13 Jul 2005 10:52:16 -0700
Message-ID: <B9782AD410794F4687F2B5B4A6FF3501021D45C0@ex1.ms.polyserve.com>

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
PolyServe

	From: Amihay Gonen [mailto:AmihayG_at_ectel.com] 
	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_at_BUDCO.com]
	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_at_ectel.com] 
	Sent: Tuesday, July 12, 2005 11:53 AM
	To: oracle-l_at_freelists.org
	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

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

Received on Wed Jul 13 2005 - 12:54:19 CDT