Re: Multi-instances cluster and ASM max lun numbers

As you stated, if your cluster can't sustain the load in case of one node
goes down it's for me questionable purpose of this solution.
Back to your questions related to DiskGroups, depending on your back-end
storage you could have different possibilities ... of course under
consideration that storage can sustain your I/O requirements.
Under assumption that storage fulfil your I/O requirements, I would first
try putting everything on the one DiskGroup per DATA/FRA. DG consist of
'many' LUN's (with multipaths) defined with normal or even high redundancy
(if you want to play safe in case of LUN problems).
But again, the solution will depend of your I/O requirements and storage
capabilities.

On Mon, Jul 30, 2012 at 8:03 PM, Stefano Cislaghi <s.cislaghi@xxxxxxxxx>wrote:

> On 30 July 2012 17:08, Robert Hanuschke <robert.hanuschke@xxxxxxxxx>
> wrote:
> > Hi Stefano,
> >
> > have you tested and experienced performance decreases when having
> combined
> > DATA / FRA / REDO luns for several databases?
> >
> > I run some clusters where up to 30 databases share the same disk groups -
> > one for data, one for fra, 2 separate for redo log mirrors on faster
> disks -
> > just separated by directories inside ASM (OMF). Not having any problems
> with
> > it.
>
> Hi Robert,
>
> yes your solution is good but what about if you have a problem with a
> LUN? In my case a single LUN problem or consistency issue might
> prevent a single database to start, in your case if you have a
> corruption on your ASM disk or any issue you will have offline al
> databases maybe.
>
> Thanks
> Ste
>
>
> --
> http://www.stefanocislaghi.eu
>
> The SQLServerAgent service depends on the MSSQLServer service, which
> has failed due to the following error: The operation completed
> successfully.
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>


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


Other related posts: