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
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.
- Performance - ASM out performs most (if not all) other file systems
- Scalability - ASM rebalances your data when you add/remove disks
- Manageability - ASM with OMF handles naming, creating, and deleting your data files for you
- Clustered - ASM provides an excellent clustered storage solution for Oracle RAC