November 24, 2013

“Everything should be made as simple as possible, but not simpler.” – Albert Einstein

I am curious as to why anyone would use ASM for a standalone database as it introduce more complexity of having to install, maintain, and upgrade Grid Infrastructure.

I asked the DBAs and here are the some responses:

ASM always bypass the OS caching layer (direct IO) which can be difficult and inconsistent using traditional FS.
ASM allows move to another type of storage in the future.
ASM provides transparent balance and migration between any type of block storage.
ASM provides online operations like adding/removing/resizing disks/LUNs from one disk array to another.

I asked a former manager who knows EMC storage and Solaris and here are his responses:

1. OS Caching: this was solved a long time ago. As you know, even plain old UFS on Solaris has been able to do this for years with Oracle.
2. Moving to another type of storage. That’s a function of either the volume manager on the OS or the array itself (both are possible and depend on your setup).
Oracle isn’t bringing anything new to the table with ASM.
3. Balance and migration. Again, a function of the volume manager and/or the array. Nothing new being done by ASM.
4. Online operations and migrations. Again, a function of the volume manager and/or the array. ASM brings nothing new.

It seems to me that ASM does, really, one thing: it eliminates the OS volume manager but at the same time expands the scope of the DBA to now include storage problems. That sounds like a distraction to me.

I would love to see a live debate on this.

Still not 100% satisfied, I started to research and explore ASM online operations.