Re: Why I don't like ASM
Date: Thu, 23 Jan 2014 23:16:46 -0700
Message-ID: <52E2054E.30005_at_gmail.com>
On 23/01/2014 8:13 PM, Dave Morgan wrote:
> Because it adds complexities and dependencies.
Depends on how you look at it, which operating system you use, and which Oracle product(s) you need. Most of my Oracle database stuff is on Linux or Solaris, with limited Windows and *no* AIX or HPUX for my current customer base. YMMV if you heavily use Windows or the other big *nixes.
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.
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'.
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.
Originally ASM was klutzy, but I've become quite happy with it in recent versions (esp 12c) and that is pretty much backward compatible.
If I want Oracle's Clusterware for either RAC, RAC One Node or Oracle Restart (the 'modern replacement for Oracle-supplied dbstart/dbshut) as of 11gR2 on Linux, I pretty much end up with an automatically installed ASM anyway.
For Standard Edition, from the 11gR2 license manual "Oracle Automatic Storage Management is required for creating and managing all Oracle database file types. Raw volumes, partitions, or third-party cluster file systems are not supported for storing Oracle database files with Oracle Standard Edition and Oracle RAC." (http://docs.oracle.com/cd/E11882_01/license.112/e47877/editions.htm#DBLIC120)
From the 11gR2 Install Guide for Linux at tahiti.oracle.com
"If you create a database during the installation, you can specify one of the following storage options for database files:
File System
Oracle Automatic Storage Management
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).
"
There is a similar phrase in the Windows Install manual for database.
Exadata, ODA ... built-in
Therefore, if I want a certified and supported config, I'm either using ASM or File System. Cluster file system? Sure - if you have a SysAdmin comfortable with that. Otherwise, training a new SA for Veritas vs ASM - is there really a difference?
As for presenting the LVMs for use as either file systems or for ASM's use, there is hte certification question discussed (for Linux) at www.oracle.com/technetwork/database/clustering/tech-generic-linux-new-086754.html
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.
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.
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. ;-)
/Hans
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Jan 24 2014 - 07:16:46 CET