Re: Why I don't like ASM Summary
- From: Dave Morgan <oracle@xxxxxxxxxxx>
- To: Oracle-L <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 10 Feb 2014 16:26:10 -0700
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@xxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxx>
>
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@xxxxxxxxx>
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@xxxxxxxxx>
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@xxxxxxxxxxx
403 399 2442
--
//www.freelists.org/webpage/oracle-l
Other related posts:
- » Re: Why I don't like ASM Summary - Dave Morgan
