RE: Why I don't like ASM
- From: Michael McMullen <ganstadba@xxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 24 Jan 2014 12:46:33 -0500
the simplest reason I have for going with ASM is it's now baked into everything
Oracle does. Docs all kind of assume ASM is being used, oracle appliances are
using ASM. So I think as a DBA you need to know ASM. You can choose not to use
it but you should have practical experience.
It's also kind of an easy intro to Grid if you use it on standalone db's. You
get familiar with the crsctl commands, has, terminology of Grid etc.
Date: Fri, 24 Jan 2014 00:17:43 -0600
Subject: Re: Why I don't like ASM
From: justin@xxxxxxx
To: oracle@xxxxxxxxxxx
CC: oracle-l@xxxxxxxxxxxxx
Where I'm at the majority of ASM installs are on RAC. We have some stand-alone
systems using ASM but that is generally because the customer wanted it. Like
anything else there are benefits and drawbacks.
The biggest drawback that I can think of is, as you said, added complexities
and dependencies. Patching, especially, becomes more complicated.
From an advantages perspective, I find that using ASM along with enterprise
hardware can give you added flexibility. For instance, if a customer needs to
migrate to faster spindles you can present the new LUNs to the nodes/server,
and then add them to the diskgroup and drop the old LUNs seamlessly. I also
like that it can all be managed from the Oracle tool-set, which means you'll
have a generally similar experience across platforms. From what I've read
there's also less I/O overhead when comparing ASM to a filesystem, but I'm sure
that's arguable and would depend on the file system being used.
Other related posts:
