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

  • From: Austin Hackett <hacketta_57@xxxxxx>
  • To: "Oracle-L@xxxxxxxxxxxxx" <Oracle-L@xxxxxxxxxxxxx>
  • Date: Wed, 15 Aug 2012 21:51:54 +0100

Hi Dana
This info doesn't exactly relate to ASM, but I hopefully it'll be of  
use to you in the future...

I've recently started a new role at shop that uses Linux, Direct NFS  
and NetApp (no ASM) and as others have suggested, the solution does  
have a number of nice management features.

However, I am finding the apparent lack of read and write latency  
stats frustrating.

Something I'm currently looking into are occasional spikes in redo log  
writes. I know these are happening because there are log write elapsed  
warnings in the LGWR trace file. When these spikes occur, NetApp Ops  
Manager reports 2 - 3 millisecond write latencies for the volume in  
question.

What I'd like to be able to do is cross-check these warnings against  
host-level io stats, but there seems to be no way of achieving this.

Using the standard Linux NFS client, iostat can show you the number of  
reads, writes etc. but not latencies. With the 2.6.17 kernel it seems  
that counters are available to report latency information, and there  
are scripts like nfs-iostat.py  out there which will display this  
info: 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=tools/nfs-iostat/nfs-iostat.py;h=9626d42609b9485c7fda0c9ef69d698f9fa929fd;hb=HEAD)
 
.

However, because Direct NFS bypasses the hosts NFS mount points  
(oracle db processes mount the files directly), it's my understanding  
the above tools won't include any operations performed by the Direct  
NFS in their output. There is a post about this here: 
http://glennfawcett.wordpress.com/2009/11/25/monitoring-direct-nfs-with-oracle-11g-and-solaris-pealing-back-the-layers-of-the-onion/

Now, whilst the v$dnfs_stats view does record the number of reads,  
writes etc, it doesn't have any latency data. Which just leaves you  
with usual v$ and AWR views like v$eventmetric, v$system_event etc.  
And if you're  trying to confirm the issue is at the host level and  
not Oracle, this doesn't help you much. So, at the moment I'm missing  
being able to run iostat and see svc_t and the like...

Incidentally, Glen Fawcett has nice script here for capturing v 
$dnfs_stats output: 
http://glennfawcett.wordpress.com/2010/02/18/simple-script-to-monitor-dnfs-activity

It's also worth being aware of bugs 13043012 and 13647945.

Hope that helps

Austin




--
//www.freelists.org/webpage/oracle-l


Other related posts: