RHEL 6.4 NFS server VM Oracle archive logs fail to write

Latest response

I have an Oracle DB on a Solaris 10 platform trying to write secondary archive logs to an NFS share hosted on a RH VM. The Oracle processes writes the file name and size but no data then hangs the DB. I successfully generated 256m files with mkfile from the Solaris box. This seem to be a problem only with the Oracle DB processes other applications are working fine. Currently configure for nfsv3.
Are there any specific RH NFS server configurations for exporting the share? Kernel parameters? Should I try to mimic an Oracle configuration in RH?

Responses

So the file gets created and the file size is set but no data written into the file? By no data do you mean the file is full of zeros or does it not have any extents allocated (ie it's a sparse file)? Since the problem only affects the Oracle DB are you sure it has any data to write out? Is the DB stuck trying to write data? We're going to need some supporting data to investigate this - would you mind opening a support case?

Our sys admin group opened support case # 01017837 late last week. We also have an Oracle support ticket open on this issue.

The files are only 8 blocks in length and have no data in them. An ls -l command shows 416808 and a du command shows 8. An od -c show some header info then all zeros. If that is the definition of a sparse file then yes it is sparse file. The NFS location is a secondary for DB archive logs and the primary is written without issue.

Check MOS (support.oracle.com) and look for metalink articles regarding NFS required parameters. There's a couple metalink articles on this. It might not be the fix to your problem but they are definitely worth reviewing and implementing.

Agree with Stephen McDonald (but I'm surprised neither Red Hat nor Oracle have this documented--or could find it for your support case--for using their own Linux server products with Oracle DBs).

We have Oracle DBs writing secondary archive logs to a 3rd-party NFS system (proprietary Unix/Linux derivative) which fails completely unless we use very specific NFS mount options (in our case, "nfsvers=3,tcp,intr,rsize=32768,wsize=32768,nolock"; I think the 'nolock' and rsize/wsize params were the key to getting it working).

The party line from MOS is that Oracle Direct NFS should be implemented for any other *nix derivative. Our problem is we have multiple NFS shares being written to, some are being migrated to RH VMs and others will stay on Solaris. If we move the DBs to ODNFS the Solaris NFS shares break.

Per Oracle the client auto.direct flags should be: "bg,hard,nointr,rsize-32768,wsize=32768,tcp,actime=0,vers=3,timeo=600"

We have added noac to help latency. We have NOT tried nolock, I think we'll try it.
Also, the Solaris NFS clients are configuration limited to MAXVERSION=3.

Thanks Stephen and James for more avenues to investigate.

Check your network health too (ie duplex mismatch errors, high runts/crc errors etc) I would try testing with dd with a large blocksize and perhaps simply copying an existing archive log file (time cp file /nfsmount) to the nfs mount and measure the throughput.
Check the following Oracle docs for NFS parameters needed for what types of Oracle files and situations etc.

Doc ID 359515.1
Doc ID 1117597.1
Doc ID 9115046.8

Good luck!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.