RE: Why I don't like ASM

From: Michael McMullen <ganstadba_at_hotmail.com>
Date: Fri, 24 Jan 2014 12:46:33 -0500
Message-ID: <BLU177-W5F306A8D8972D7E5E8009A6A10_at_phx.gbl>



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_at_n0de.ws
To: oracle_at_1001111.com
CC: oracle-l_at_freelists.org

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.                                                

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 24 2014 - 18:46:33 CET

Original text of this message