Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: RAC and ASM disk layout

Re: RAC and ASM disk layout

From: Ghassan Salem <>
Date: Mon, 12 Jun 2006 10:47:44 +0200
Message-ID: <>

For sure, if ASM screws up, it's more dangerous than CBO screwing up, but It seems to be a fairly stable piece of code, and there are not that many bugs in it.
If anybody has a problem with what it does (e.g. failure groups) you may (or NOT) use that feature, or not use ASM at all. Reading the emails on this thread, one thinks that ASM is a very dangerous option, that you're not supposed to use (or use at your risk). I think the picture is not that bad.


On 6/12/06, Niall Litchfield <> wrote:
> On 6/12/06, Robert Freeman <> wrote:
> > >> Or, in some situations, a living hell. I don't want to take a chance.
> > >> God might play dice, but I do not.
> > I agree.... until a product is stable, I prefer not to use it. However,
> > one
> > has to guard against the other side.... One has to guard against the
> > "Oh, I
> > tried that in 7.3, and found a bug in it so I'll never use it again".
> > That
> > is way to far on the other side of the fence.
> >
> > Cheers!
> There's also risk and reward to be considered here. There are two main
> risks to the CBO which was also suggested as a complex piece of software
> that is ill understood (in detail anyway - my take is that in *principle *it is fairly well understood these days) that I can see. These are:
> 1) Your application, or more accurately rather important parts of it, may
> well perform poorly in terms of response time (or throughput but folk don't
> seem to care about that these days).
> 2) You may get wrong results - indeed you may get wrong results and not
> notice.
> Of course we all tend to pay attention to the first category largely
> because it is obvious and results in highly paid and or highly influential
> managers, owners and so on shouting at us. Moreover we get lots of kudos
> for fixing it - and actually most DBA type people are relatively good at
> fixing things. The second problem is much more serious, but rarer, and
> anyway the highly paid shouters might not notice it, and if they do will
> likely blame the app or the developer.
> Now with ASM the risks are more like:
> 1) Your data may be corrupted silently.
> 2) Your data may become unavailable and unrecoverable.
> 3) Your cluster software (not strictly ASM here I admit) may start
> asking nodes to reboot regularly and kill availability.
> I see those as quite significant risks for what is described as an
> optional component. The advantages of ASM would have to be quite significant
> to outweigh them. Now my take is that there are circumstances where the
> advantages do make ASM a good choice, and also that Oracle have done a very
> good job on risks 1) and 2), and are working hard on 3), but I still think
> that ASM screwing up is a far more serious risk to take than the CBO
> screwing up - and how long did it take for CBO to be widely adopted?
> > --
> > Niall Litchfield
> > Oracle DBA
> >

Received on Mon Jun 12 2006 - 03:47:44 CDT

Original text of this message