Re: Multi-instances cluster and ASM max lun numbers
- From: Robert Hanuschke <robert.hanuschke@xxxxxxxxx>
- To: Stefano Cislaghi <s.cislaghi@xxxxxxxxx>
- Date: Tue, 31 Jul 2012 17:07:50 +0200
Hi Stefano,
sure, everything comes with a price.
I assume the possibility of such a logical corruption (physical failures
should have been taken care of with redundancy of any form) is pretty low,
though. Never had a problem like that until now. Maybe the other list
members can help with their experiences to get a bigger, statistically more
relevant picture.
Maybe a compromise would be possible - bundle some of the less critical
databases into the same disk groups to at least save somewhat of the total
number needed.
Thinking another direction - a Data Guard configuration to another cluster
(so - no single point of failure) is a solution one could evaluate. Of
course, that will also have some cost attached to it.
In the end, that's a cost/risk decision you have to make.
Best regards,
Robert
http://robertvsoracle.blogspot.com
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.
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
