Monday, October 17, 2005

Wicked ORA-27054, Solved

You may recall that I've been having problems getting 10gR2 backed up to NFS mounted disk. After we got bounced around a couple groups of Oracle Support, we finally landed into the capable hands of David Marshall.

After much research on David's part and some testing on our own, we settled on using the following parameters to mount our NFS filesystems for the purpose of backup:

rw,bg,intr,hard,timeo=600,wsize=32768,rsize=32768,nfsver=3,tcp

So all is well now. Our 9.2 backups complete in the same time and our 10.2 backups complete in an acceptable time. Now if we just knew which one of those parameters did it, we'd complete the education process.

11 comments:

Joel Garry said...

Google about, and you may find things like nfsver=3 enables client-side caching as well as less overhead and more data movement over the net. The tcp parameter was probably the major reason, though - remember my last reply? There are dependencies on the linux kernel, too, before 2.5 there was a flush every M, and 2.6 allows 32K blocks (before that it was 8K blocks, even though it appeared larger ones worked).

See http://nfs.sourceforge.net/nfs-howto/performance.html

kwbvgqbj

Frank Carnovale said...

Jeff,
thanks very much indeed for taking the trouble to catalogue this problem and the solution. I hit this message, not when setting up regular backups, but simply in wanting to use NFS as proposed in the Data Guard setup when running the kick-off DUPLICATE TARGET DATABASE FOR STANDBY .
I was absolutely stuck.. A google on the ORA message found your article. I really appreciate the help.

Anonymous said...

FYI, on HP 9000 running 10.2.0.1 and connecting to an NFS mount on a BSD-based server, I used these options:

vers=3,proto=tcp,hard

Exporting 43GB is taking roughly 10min over a GigE link.

Kevin Closson said...

Good thread!

Oracle looks at the mount options at runtime. The most critical in Oracle10gR2 for nfs are tcp and nfsvers. If you don't have these correct, the assignment to the filesystemio_options init.ora parameter is essentially ignored.

My NAS paper at http://kevinclosson.wordpress.com/written-works-and-presentations/ goes over this a bit.

Anonymous said...

On Solaris 9, we patched and changed the NFS mount from SOFT to HARD and it resolved our issue.

--Keith

Anonymous said...

ok - working optioons for RH Linux:
rw,noac,bg,intr,hard,timeo=600,wsize=32768,rsize=32768,nfsvers=3,tcp

Please note that the noac option had to be added due to this being a RAC instance.

Anonymous said...

For future reference, we just ran into this error on Solaris when NFS mounting with default options and trying to use Oracle RMAN. We solved it by explicitly setting these NFS mount options on the Oracle server (even though some are obviously redundant):
rw,bg,hard,nointr,proto=tcp,
vers=3,timeo=600,rsize=32768,
wsize=32768,actimeo=0

NFS server: Sun X4500 "Thumper", Solaris 10 8/07 (Update 4) for X86, Kernel patch 127112-08

Oracle server: Sun T5120, Solaris 10 8/07 (Update 4) for SPARC, Kernel patch 120011-14

Anonymous said...

Should you see this problem on redhat,
you may need to force the nfs server to say nfs4 is not avaliable.
# echo "RPCNFSDARGS='--no-nfs-version 4'" >> /etc/sysconfig/nfs
# service nfs --full-restart

Anonymous said...

Working options on AIX5 and Oracle 11 are:

wsize=32768,rsize=32768

JXM

NerdyRedneck Rob said...

Thanks everyone for putting this out there- This is so much better than searching gawd awful metalink!

Anonymous said...

This fixed the issue for me too. I just had to leave out the "nfsver=3" in the options on the mount.