Re: RAC and ASM disk layout

  • From: "Ghassan Salem" <salem.ghassan@xxxxxxxxx>
  • To: niall.litchfield@xxxxxxxxx
  • Date: Mon, 12 Jun 2006 10:47:44 +0200

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.

rgds

On 6/12/06, Niall Litchfield <niall.litchfield@xxxxxxxxx> wrote:

On 6/12/06, Robert Freeman <robertgfreeman@xxxxxxxxx> 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 > http://www.orawin.info


Other related posts: