It is public knowledge that NFS is SLOW solution for Oracle in any way. Even though it is a supported option for Oracle RAC, it is VERY BAD idea, because of the over caching and the fact that Oracle will have to use the default system driver to send it commands and requests.
Thankfully, there is a solution for that called NFS Direct, which bypasses the default NFS driver and issues direct requests to the NFS. Direct NFS provides faster performance than what can be provided by the operating system's NFS driver as Oracle bypasses the operating system and generates exactly the requests it needs (no user configuration or tuning required). Data is cached just once in user space, which saves memory (no second copy in kernel space). Performance is further improved by load balancing across multiple network interfaces (if available).
Direct NFS is fairly easy to implement. Since it searched for the default location for NFS information:
/etc/mtab
/etc/fstab
/etc/oranfstab
Oracle needs to find the NFS in at least one of these files. P.S. Bear in mind that the oranfstab has different configuration syntax than the usual /etc/fstab:
server: TAURUS local: IP_NFS_SERVER path: IP_DEST_SERVER export: /be_ora_logs mount: /backup
To enable the Direct NFS after that is very easy:
cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk dnfs_on
cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk dnfs_off
After you have enabled the NFS, a message in the alert log should be displayed:
Oracle instance running with ODM: Oracle Direct NFS ODM Library Version 4.0
By default, Windows “blocks” writes by NFS direct….not so smart, so check that from windows as follows:
PS C:\Windows\system32> reg query HKLM\Software\Microsoft\ServerForNFS\CurrentVersion\Exports /s
HKEY_LOCAL_MACHINE\Software\Microsoft\ServerForNFS\CurrentVersion\Exports\0
Path REG_SZ F:\be_ora_logs
Alias REG_SZ be_ora_logs
GlobalPerm REG_DWORD 0x1
AllowAnonymousAccess REG_DWORD 0x2
RestrictChown REG_DWORD 0x1 <- This little fellow.
SymbolicLinks REG_DWORD 0x1
TruncateNames REG_DWORD 0x0
UnmappedUID REG_DWORD 0xfffffffe
UnmappedGID REG_DWORD 0xfffffffe
Encoding REG_DWORD 0x7
SecurityFlavors REG_DWORD 0x2
NumClients REG_DWORD 0x5
Clients REG_SZ N,server1,server2
PS C:\Windows\system32>
If you change it to “0”, should be fine:
PS C:\Users\Administrator> reg add HKLM\Software\Microsoft\ServerForNFS\CurrentVersion\Exports\0 /v RestrictChown /t REG_DWORD /d 0
PS C:\Windows\system32> reg query HKLM\Software\Microsoft\ServerForNFS\CurrentVersion\Exports /s
HKEY_LOCAL_MACHINE\Software\Microsoft\ServerForNFS\CurrentVersion\Exports\0
Path REG_SZ F:\be_ora_logs
Alias REG_SZ be_ora_logs
GlobalPerm REG_DWORD 0x1
AllowAnonymousAccess REG_DWORD 0x2
RestrictChown REG_DWORD 0x0 <- Fixed
SymbolicLinks REG_DWORD 0x1
TruncateNames REG_DWORD 0x0
UnmappedUID REG_DWORD 0xfffffffe
UnmappedGID REG_DWORD 0xfffffffe
Encoding REG_DWORD 0x7
SecurityFlavors REG_DWORD 0x2
NumClients REG_DWORD 0x5
Clients REG_SZ N,server1,server2
After that, restart the NFS service and all should be running normally :)
You can verify if the NFS driver has been configured as follows:
SQL> select * from v$dnfs_servers;
ID SVRNAME DIRNAME MNTPORT NFSPORT NFSVERSION WTMAX RTMAX CON_ID RDMAENABLE RDMAPORT SECURITY
---------- -------------------- --------------- ---------- ---------- ---------------- ---------- ---------- ---------- ---------- ---------- ----------
1 10.200.15.30 /be_ora_logs 2049 2049 NFSv3.0 32768 32768 0 No 0 sys
SQL>
That shows us that the NFS is configured on server: 10.200.15.30 on this partition: /be_ora_logs
You can also verify if the NFS is ACTUALLY used during a backup. You should be able to observe the following output:
SQL> select CH_ID, SVR_ID, SENDS, RECVS, PINGS from v$dnfs_channels;
CH_ID SVR_ID SENDS RECVS PINGS
---------- ---------- ---------- ---------- ----------
0 2 366 608 0