Re: Why I don't like ASM Summary
Date: Mon, 10 Feb 2014 16:26:10 -0700
Message-ID: <52F96012.4070608_at_1001111.com>
Thanks to all who responded. Please note that there was no argument that about the fact ASM should be used for RAC. I have managed raw disks, it is not easy.
>> Date: Fri, 24 Jan 2014 00:17:43 -0600
>> Subject: Re: Why I don't like ASM
>> From: Justin Mungal <justin_at_n0de.ws>
> 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.
Okay, a fairly rare situation, but it does prevent an outage.
> 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.
:) I agree
From: "Uzzell, Stephan" <SUzzell_at_MICROS.COM> 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.
In the old days I would agree with you but now, add another array oh no, I have 4 mount points, the horror. :)
> Date: Thu, 23 Jan 2014 23:16:46 -0700
> Subject: Re: Why I don't like ASM
>
> Myself - I see ASM simply as "Yet another File System and Logical Volume
> Manager' rolled into one. Since the OS needs one OR MORE file systems,
> and since it is often easier to manage disk as LVMs, it is nice to have
> a set of s/w that collapses both into one. As for install automation -
> it uses the typical Oracle OUI Silent Install, which can easily be
> embedded in a script. Really the only hassle I see is getting the
> storage presentation from the Storage Admin.
I agree
> And yes, ASM feels a lot like a JBOD LVM, and seems to fight against the
> modern innovative massive RAID 5-based storage frames. The only concern
> I really have with the big storage arrays is the Silent Raid-5
> Corruption problem, which is slowly being addressed in that industry.
>
> There is no more dependency on this as on any other file system and
> indeed, there can be additional disk-related "security" - if the file
> system kernel module crashes for the disk you have the database data on,
> the data damage can be severe because the file system or disk frame and
> the database do not communicate well (database says - write, frame says
> 'aaaargh', database assumes written and thinks the commit has actually
> happened), whereas if ASM crashes is stops the current write and
> crashes any existing transactions, guaranteeing database consistency.
> Alex Gorbachev does a nice demo of this, and nicely shows what happens
> when multiple disks crash in a striping config vs ASM 'redundancy'.
The only write that matters is to the redo log and if that is corrupt
then any existing transactions are gone.
>
> In addition, most sys admins do not roll the OS file systems for "few,
> very large file" requirements as they have been trained for the typical
> "many, very small (under a few MB) file" environments seen by most PC
> users. And setting the disk parameters for an OS wrong can be - well,
> just plain wrong for RDBMS operation.
I agree, however, to my mind the DBA and the sysadmins need to collaborate on physical machine configuration.
> Installing files on raw devices is no longer an option during
> installation. You must use a file system or Oracle Automatic Storage
> Management (Oracle ASM).
As I say, I wish I had ASM when I needed it :)
>
> For me, it's just another tool, and in particular, it's just another
> 'file system'. I've learned to be comfortable with it, and it has
> served me reasonably well in the past 2 years - even though I don't
> quite like the feel of running SQL to understand how my LVM is
> operating. I do heavily reference Nitin's Oracle Press books on ASM for
> scripts and concepts.
Exactly, I just see in situations where it appears unnecessary or overkill and I am trying to find out if there is a good reason behind it.
> So DBAs who crank out small databases for many customers, it is an extra
> step, potentially a pain, and something else to monitor and manage. For
> single-employer DBAs with a number of fairly large DBs, it can be
> simpler than alternates - once you get used to it. Some of my very
> large customers, the storage group has basically taken responsibility,
> eliminating the DBA complexity concern.
Very similar to our environments, either tiny where we are the experts, or "enterprise" where we have access to hardware guys
> But you are correct - for the DBA, now taking over some of the
> SysAdmin's and Storage Admin's work and this does add complexity. Then
> again, if you use Oracle's admin-automation features, you are supposed
> to have extra time on your hands, so this would fill that gap.
:)
>
> Date: Tue, 28 Jan 2014 06:32:18 -0800 (PST)
> From: Yong Huang <yong321_at_yahoo.com>
>
> In case nobody has mentioned. I haven't heard anybody using ASM accidentally deleted a datafile, logfile, or control file, which definitely occurs more often when you use a file system. The asmcmd environment and the fact that a file's full path begins with + serve as a reminder, possibly subconsciously, that the file is not to be deleted lightly.
> Yong Huang
>
> Date: Tue, 28 Jan 2014 07:53:15 -0700
> From: Tim Gorman <tim_at_evdbt.com>
> Subject: Re: Why I don't like ASM
>
> Good point! However, if the ASM file is in use by an instance, ASMCMD
> gives an error message, so even those who ignore subconsious reminders
> are protected from themselves.
Now you guys have given me something to think about. :)
>
> Date: Tue, 28 Jan 2014 10:07:49 -0800 (PST)
> From: Yong Huang <yong321_at_yahoo.com>
> Subject: Re: Why I don't like ASM
>
> Thanks Tim. You're right. Trying to delete a file when there's an ASM client using it throws ORA-15028.
Cannot they be deleted at the disk level? Again I think you have a real benefit here, I'm just exploring all aspects. Time to run a test I guess.
Thanks to all once again
Dave
-- -- Dave Morgan Senior Consultant, 1001111 Alberta Limited dave.morgan_at_1001111.com 403 399 2442 -- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 11 2014 - 00:26:10 CET