Re: ASM

  • From: "Randy Johnson" <oraclelist@xxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 20 Oct 2008 09:14:23 -0500

I tried not to be too long winded with this post but as you can see I didn't
quite pull it off. So for those of you who are patient enough here is my
input on the topic.
 
I've been working with ASM for over three years now. I could walk through
the list of ASM features but I'm sure we've all seen or heard the sales
pitch. What I can offer this conversation is my experience with the product.
Overthe past 3 and half years I have installed ASM in RAC and non-RAC
production environments for over 20 clients. One was a RAC implementation
for a 13T data warehouse. Another was an enterprise wide conversion of appx
20 databases to ASM. The results have been universally positive.
 
Some of the arguements against using ASM were:
 
Additional instance for ASM
 --------------------------------------------    
Agreed, but it is a greatly simplified instance. It's never crashed on me.
Only a few parameters you set once and never touch again (usually). Truly a
"set it" and "forget it" instance.
 
file management is simpler
------------------------------------------ 
The best way to make file management simpler is not to have to manage them
at all. Using OMF + ASM that is exactly what you get. No file management
needed. 
 
storage admins don't have easy direct access to see what's on disk
----------------------------------------------------------------------------
-------------------------
I don't know about you guys, but I really don't want storage admin's mucking
around in my file systems. Be that as it may, there are several ways to look
at the file system structure in ASM.
 
  - FTP interface. Browse your entire ASM disk environment just like you
would standard file systems (in a tree like fashion).
  - HTTP interface. Browse your ASM disk environment using any Web browser.
  - asmcmd interface. Gives you typical file system commands like du, ls,
and find. More commands were added to this interface in 11g and I expect
there will be more in the future.
 
ASM only works for Oracle files
-------------------------------------------------------- 
Agreed, but I can also see it from a different point of view. Consider this,
whether you are running a database on Windows, Linux, AIX, Solaris, HP/UX,
(the list goes on), your database file system, management tools, scripts,
etc. will always work the same. You don't have to worry about using a
different file system product for each operating environment. Also, consider
this, ASM is the ONLY "file system" that is optimized for the Oracle RDBMS.
I've run simple performance comparisons between ASM and Veritas QIO file
systems and found ASM  to be very slightly faster (<5%). Compared to a
standard file system, ASM was 8-10% faster. On very large, or very busy
databases I'd expect the performance improvement would be much greater. It
is faster and it's free. And standard file systems do not automatically
rebalance my data when I add more disks. Incidentally, this automatic
rebalancing may allow ASM to outperform raw device databases as well,
especially for databases that have undergone significant growth.
 

Here are some  of the benefits that ASM brings to the table
 
Performance metrics are automatically collected and easily available
----------------------------------------------------------------------
For example:
  COL AVG_MS_READS  FORM 9999.99
  COL AVG_MS_WRITES FORM 9999.99
  COL NAME FORM A7
  SELECT DG.NAME DG,  D.NAME DISK, D.TOTAL_MB, D.FREE_MB,
         D.TOTAL_MB-D.FREE_MB USED_MB, 
         D.READS, D.READ_TIME, D.WRITES, D.WRITE_TIME,
         (D.READ_TIME/D.READS) * 1000 AVG_MS_READS,
         (D.WRITE_TIME/D.WRITES) * 1000 AVG_MS_WRITES
    FROM V$ASM_DISK D,
         V$ASM_DISKGROUP DG
   WHERE D.GROUP_NUMBER = DG.GROUP_NUMBER;
 
DG      DISK    TOTAL_MB    FREE_MB    USED_MB      READS  READ_TIME
WRITES WRITE_TIME AVG_MS_READS AVG_MS_WRITES
------- ----- ---------- ---------- ---------- ---------- ----------
---------- ---------- ------------ -------------
DATA      VOL1      97660       5853      91807        182      1.401
718500   1495.087          7.70          2.08
FLASH    VOL2      97660      89311       8349    2968799   5592.286
977622   2108.097         1.88          2.16
 

Disks can be added/removed and your data is automatically rebalanced 
----------------------------------------------------------------------------
------------------------------ 
Think about what happens when you add disk space to your file system. You
add the disk and then grow into it. Unless you go about moving files around
to redistribute your IO load you end up with all your IO going to the newest
disks. Assuming the data you access every day is the most current (maybe not
such a  big assumption for most applications). Over the years you will
continue to use a smaller and smaller fraction of your available IO
bandwidth. That is to say, your most popular data will be located on the
disks most recently added. There are other products that will redistribute
data like this for file systems but there is an additional charge for that.
 

Frees Up File Cache Memory
---------------------------------------------- 
We've all heard it before. There is no reason to cache Oracle database data
files at the file system level. Yet a majority of us do just that. Like raw
devices, ASM does not use file cache. That leaves more memory to cache the
files you really need to cache. If that means you don't need as much memory
for file cache you can re-allocate that extra memory to be used in your SGA
or other programs on the system.
 

ASM is a strategic technology of Oracle, Corp.   
---------------------------------------------------------------------- 
This is not the most compelling reason to move to ASM but it should not be
totally ignored. 11g R1 added more manageability features and I'm sure we'll
see more going forward.
 

In conclusion there are several reasons that I believe you should seriously
consider a move to ASM for clustered and non-clustered databases. 
 
  1) Performance - ASM out performs most (if not all) other file systems
  2) Scalability - ASM rebalances your data when you add/remove disks
  3) Manageability - ASM with OMF handles naming, creating, and deleting
your data files for you
  4) Clustered - ASM provides an excellent clustered storage solution for
Oracle RAC
 

Randy Johnson
Enkitec, LP.
  • Follow-Ups:

Other related posts: