VLDB ASM & SAN Striping Question

  • From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 6 Jun 2012 07:22:15 -0500

I am curious if anyone on this list has worked on disk striping at the SAN 
layer and then at the ASM layer?  Specifically, I want to know if you drilled 
all the way down to the physical devices on the SAN (controllers and physical 
disks) to make your hardware stripes?
In the my current IT dept (and in my previous one) the SAN administrators 
weren't SAN experts (no fault of theirs) and I was told they couldn't stripe 
disk groups across specific controllers and specific disks (meaning they didn't 
know if it was possible and if it was they didn't know how to accomplish it).

I was reading the Oracle doc "Oracle Database VLDB and Partitioning Guide 11g 
Release 2 (11.2) at: 
http://docs.oracle.com/cd/E11882_01/server.112/e16541/vldb_storage.htm when I 
saw this paragraph:

"Oracle ASM can be used on top of previously striped storage devices. If you 
use such a configuration, then ensure that you do not introduce hot spots by 
defining disk groups that span logical devices which physically may be using 
the same resource (disk, controller, or channel to disk) rather than other 
available resources. Always ensure that Oracle ASM stripes are distributed 
equally across all physical devices."

I understand striping really well.  What I'm having a hard time is finding the 
"how" in creating LUNS across specific controllers and only specific disks 
attached to those controllers in a typical SAN (specifically we're using an HP 
EVA 8100).  Who of you have actually done this - drill down to the controllers 
and devices and how hard was it to convince the SAN administrator to help 
accomplish this?

Any input and thoughts are appreciated.

Chris Taylor

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

Any views and/or opinions expressed herein are my own and do not necessarily 
reflect the views of Ingram Industries, its affiliates, its subsidiaries or its 


Other related posts: