RE: Why I don't like ASM
- From: "Uzzell, Stephan" <SUzzell@xxxxxxxxxx>
- To: "'samuel.guinales@xxxxxxxxx'" <samuel.guinales@xxxxxxxxx>, "ganstadba@xxxxxxxxxxx" <ganstadba@xxxxxxxxxxx>
- Date: Mon, 27 Jan 2014 15:54:17 +0000
I would add that it certainly makes database growth easier... For RAC, using
OCFS, and having datafiles on H:, I:, J:, K:, &c. as the database grows - not
so hot. For non-RAC, using NTFS - same problem. Give me ASM where I can just
throw more disks into the diskgroup - one less thing to worry about.
Stephan Uzzell
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Samuel Guiñales Cristobal
Sent: Monday, 27 January, 2014 10:50
To: ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Why I don't like ASM
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<mailto:samuel.guinales@xxxxxxxxx>>
OCP10g,11g
Senior Oracle Database System Engineer
FUJITSU
On 24 January 2014 18:46, Michael McMullen
<ganstadba@xxxxxxxxxxx<mailto: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<mailto:justin@xxxxxxx>
To: oracle@xxxxxxxxxxx<mailto:oracle@xxxxxxxxxxx>
CC: oracle-l@xxxxxxxxxxxxx<mailto: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:
