EMC is recommending a min. of 2 disk groups so that you can balance I/O's across two Logical Volumes (Metas in your DMX). This way you will stripe at the ASM level and at the host level as well and you'll end up with a double stripe. Here is my 2 cents on ASM disk group recommendation if you can afford the disks. ASM diskgroup 1 - 2 LUNs - for Datafile and Indexes ASM diskgroup 2 - 2 LUNs - for Redo logs ASM diskgroup 3 - 2 LUNs - for Archive logs Raj On 3/7/06, K Gopalakrishnan <kaygopal@xxxxxxxxx> wrote: > > Tim: > > ASM uses SAME methodology internally and your data is striped and > mirrored across ALL avaiable disks. So I donot understand why would > you need a traditional split. If you need more redundancy, you can go > for triple mirroring from ASM or other mirroring at EMC level. > > > If you are worried about the meta data failures,corruptions.. I have > not seen any. But FYI, ASM Metadata also triple mirrored ! > > KG > > > On 3/7/06, Tim Onions <att755@xxxxxxxxxxx> wrote: > > Dear All > > > > Management have committed to getting a new EMC DMX3 top of the range > SAN. We > > will be running a Linux RHEL4 10gR2 RAC database against it. We are some > > months away from go live so have lots of testing and such to do. However > EMC > > are asking for the disk layout detalis now, and reading Oracle/EMC docs > they > > say all we need is 2 ASM disk groups. The trouble is one will be 1.2Tband > > contain all our datafiles (system, temp UNDO included) and that don't > feel > > right. Changes to the EMC configuration will be expensive and impact > other > > SAN usage if done later on. > > > > Does anyone have any practical experience on ASM on a SAN and are thus > able > > to comment on whether Oracle docs are right in saying place all this > data in > > a single disk group? Any good reasons for not opting for a more > traditional > > split? > > > > TIA > > > > Tim Onions > > > > _________________________________________________________________ > > The new MSN Search Toolbar now includes Desktop search! > > http://toolbar.msn.co.uk/ > > > > -- > > //www.freelists.org/webpage/oracle-l > > > > > > > > > -- > Best Regards, > K Gopalakrishnan > Co-Author: Oracle Wait Interface, Oracle Press 2004 > http://www.amazon.com/exec/obidos/tg/detail/-/007222729X/ > -- > //www.freelists.org/webpage/oracle-l > > >