More simple reason, with time, asm has become in standard, build in oracle package with RAC, is easier to manage than other solutions, cheaper,etc.. Regards --- Samuel G. Cristobal <samuel.guinales@xxxxxxxxx> OCP10g,11g Senior Oracle Database System Engineer FUJITSU On 24 January 2014 18:46, Michael McMullen <ganstadba@xxxxxxxxxxx> wrote: > 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. > > > >