Re: VLDB ASM & SAN Striping Question
- From: goran bogdanovic <goran00@xxxxxxxxx>
- To: ChrisDavid.Taylor@xxxxxxxxxxxxxxx
- Date: Sat, 9 Jun 2012 01:02:16 +0200
IMO what you are asking is tied to the functionalities (possibilities) of
storage array ... in EMC Clariion it's possible to create a so called
'Single Bound Disk' raid group (RG) which is essentially a JBOD i.e. a
single-disk RG (no striping or redundancy).
with JBOD you and your SAN admin can then play as you like (almost) ;-)
goran
On Wed, Jun 6, 2012 at 6:04 PM, Taylor, Chris David <
ChrisDavid.Taylor@xxxxxxxxxxxxxxx> wrote:
> I'm not as much interested in the EVA specifically as I'm interested in
> the process in general (identifying controllers and physical disks) and
> convincing the SAN administrator to take this fine grained approach to
> building LUNS.
>
> 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 10:38 AM
> To: Taylor, Chris David
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: VLDB ASM & SAN Striping Question
>
> I haven't poked around the EVA line in a while, but if I remember
> correctly,what you describe is basically impossible in an EVA. The way an
> EVA works, you make a disk group, and all of the LUNs in that disk group
> are dynamically striped across the disks in that group.
> You could theoretically make a 2-disk group, and one LUN from those, but I
> *think* you have to assign hot spares to individual disk groups, and hence
> you'd burn a lot of storage just on spares in that architecture.
>
> What you could do is ask them to make sure that when you add a new LUN, it
> comes from a different disk group than the current LUNs.
> Probably your best bet.
>
> Matt
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
