RE: VLDB ASM & SAN Striping Question

Okay - now I'm following.  My apologies.

So the key is to focus on disk groups - and in a different product, a SAN 
administrator should be able to identify specific disks easily to assign to a 
disk group?  I would assume this would follow to controllers as well?

Something like this:

1. Identify Controllers (primary controllers as I assume more than 1 controller 
can control the same disk in case of failure in the controller?)
2. Identify Disks attached to that controller
3. Create DG from those disks attached to that controller

*OR* would it make more sense from an IO perspective to:

1. Identify Controllers
2. Identify Disks attached to all controllers
3. Create DG from disks from each controller (instead of disks on 1 controller?)

I'm imagining a scenario like:

Disks 1,2,3,4 on controller1
Disks 5,6,7,8 on controller2

Create DG#1 on Disks 1,5 instead of Disks 1,2 to spread IO across both the 
disks and the controllers?


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 
employees. 


-----Original Message-----
From: Matthew Zito [mailto:matt@xxxxxxxxxxxxxxxxx] 
Sent: Wednesday, June 06, 2012 11:13 AM
To: Taylor, Chris David
Subject: Re: VLDB ASM & SAN Striping Question

Right, and my point was just that when you create a disk group, every LUN gets 
striped across *all* of the disks.  So the right way to handle this is to just 
request a 1 LUN = 1 DG mapping, that way, when you stripe across LUNs you're 
guaranteed to be on different disks.

However, odds are, you have a giant disk group, and are making LUNs out of that 
disk group.  There is no way, in an EVA, to say, "Map this LUN to just these 
two disks in the disk group".  Everything is striped across all disks in the 
disk group.

With these kinds of arrays, it is almost impossible to attempt to optimize at 
an Oracle level for physical placement, and in my experience, it is almost 
never worth the effort in terms of time and cost.

Matt

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

Other related posts: