Re: 10g ASM is junk ...

Howard J. Rogers wrote:

> The only thing I would say is that ASM is not just software RAID. RAID (1)
> merely stripes, not intelligently/evenly distribute -which is what ASM is
> trying to do. Plus, last time I checked you can't just plug in an extra disk
> to a RAID stripe set. You can (allegedly) with ASM, which 'grows' as new
> hardware is made available to it.

And that is very much the whole argument for using it. If one has the knowledge in-house to do all those things AS WELL as RAID configurations, then fine: don't use ASM. If one doesn't, then why not? Apart from the obvious "first release", yadda yadda.

> As for being worried about your ASM instance failing and "BANG - the other
> instances can't see the disks any more"... one could just as easily have
> written that about a hardware RAID controller going BANG! But in any case, I
> don't think it's true. The job of the ASM instance is merely to hand each
> database instance an extent map as it starts up. Once the database instance
> is up and running, it is itself responsible for doing all the I/O, not the
> ASM instance. So the ASM instance can die, and your existing databases will
> still be viable.

That was my understanding as well. Can anyone confirm if it isn't? I can't see ASM replacing the I/O control of any database instance. It merely provides the metadata for each instance to self-manage the I/O according to an overall global "policy". Or that is what I was led to believe.

> effectively, 'you can't be in your right mind if you use it' is calculated
> to make that happen particularly well!

Ah well, you see: ASM totally destroys the argument to measure performance of a DBA through the BCHR...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam