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

From: Martin Berger <martin.a.berger_at_gmail.com>
Date: Tue, 7 Aug 2012 16:32:18 +0200
Message-ID: <CALH8A93FuAZT7F+c51uHEQK3KCcNv1d+ZV63MMLtUG9xF_XmYQ_at_mail.gmail.com>



Dana,
from the documentation:
http://docs.oracle.com/cd/E14072_01/server.112/e10500/asmprepare.htm

   Oracle ASM supports NFS files as Oracle ASM disks. Oracle Database has built-in support for the network file system (NFS) and does not depend on operating system (OS) support for NFS. Although NFS and Oracle ASM have overlapping functionality, Oracle ASM can load balance or mirror across NFS files. Oracle ASM also supports Oracle Direct NFS (dNFS) client that integrates the NFS client functionality directly in the Oracle Database software stack.

I would use ASM _AND_ dNFS together.
So I still can use the advantages of ASM like striping / mirroring, but also online storage migration - even across technologies - with high flexibility.

I see a simple reason ANY Storage-Vendor recommends to REMOVE ASM: Without ASM it's much harder to move away from their Storage, even if it does not fit well ;-)

my .02€

On Tue, Aug 7, 2012 at 2:45 PM, Dana Nibby <dananrg_at_yahoo.com> wrote:

> 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
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Aug 07 2012 - 09:32:18 CDT

Original text of this message