ASM of any significant value when switching to Direct NFS / NetApp / non-RAC?

We currently use ASM for all instances on a block storage SAN. The sysadmins 
and storage admins are migrating all 11g instances over to NetApp storage with 
Direct NFS (RHEL on VMWare is in the mix as well--and VMWare is new for us; so 
is SMO). They're strongly advising us to discontinue using ASM in this new 
environment. Their Rationale: no demonstrable value worth the complexity of 
(them) managing ASM; that the ASM functionality isn't being used. And that ASM 
made sense when using a block storage SAN environment but not in the new one. 
"Why would you layer an LVM atop an LVM?" they ask. Since we always specify 
External Redundany for ASM diskgroups, etc.
 
Although I'm certain there is a lot of functionalty crossover, where do Direct 
NFS and ASM capabilities *not* intersect? In other words, can any compelling 
case be made to keep ASM in a NetApp/Direct NFS environment? If so, which 
features of ASM make the case (if there's one to be made). As DBAs without root 
or storage access, will we lose any ability (e.g. file mgt) to do things 
ourselves with Direct NFS that we had with ASM? Would the sysadmins and/or 
storage admins be taking over more of the workload under Direct NFS? I 
certainly don't want to persist something that adds another layer of 
abstraction if there's no clear value--what is implemented must be supported. 
But I want to be sure we DBAs aren't handicapping ourselves before we agree to 
"no more ASM" given the separation the duties, etc.
 
Anyone here, in a non-RAC environment, continue to use ASM with Direct NFS? 
Though there's evidently no reason why you can't have both, I'm wondering what 
the strongest case there is in favor of using both. And what's the strongest 
case for jettisoning ASM in our new environment? The same one already made 
above?
 
Best,
 
Dana 
--
http://www.freelists.org/webpage/oracle-l


Other related posts: