- Written by: ilmarkerm
- Category: Blog entry
- Published: December 6, 2022
If you use Oracle database on NFS, make sure you use Oracle DirectNFS, which is a built in NFS client in Oracle database kernel. This makes it possible for the database software to access files on NFS share without calling the operating system kernel. The performance improvement is significant!
I use NFS a lot for Oracle databases, because it is so much easier to manage than any block device based system, specially when using Oracle RAC. Or when you need to clone the database.
And then one day I noticed that some Data Guard standby databases, rather large and busy ones, started to lag – more and more. Confusion started – why – same standby on another datacenter on same type of storage is completely fine. It was fine on this system also up to last week. What has changed? The long confusion part is not important… Until realised, that on the system that was working fine, Linux OS command nfsiostat (displaying Kernel level NFS statistics) – it showed hardly any traffic at all. But on the problematic system, nfsiostat displayed a very busy NFS traffic. The aha moment – DNFS! Linux kernel should not be able to see DNFS traffic.
When doing major OS upgrades, after you should also relink your Oracle database binaries:
Relinking Oracle Home FAQ ( Frequently Asked Questions) (Doc ID 1467060.1)
The note above even states that you should relink after every OS patch… So I just incuded relinking to the playbook that replaces database VM OS root disk. But since DNFS (probably other similar features too, like Unified Auditing??) needs to be linked into Oracle kernel separately – executing “relink all” silently disables DNFS.
Lets test. I’m using Oracle RDBMS 19.15.2, single instance. First I have DNFS enabled and working:
SQL> select id, svrname, dirname, nfsversion from v$dnfs_servers; ID SVRNAME DIRNAME NFSVERSION ---------- ---------- --------------- ---------------- 1 10.122.9.9 /pt101 NFSv3.0
Then I shut down the database and execute relink all.
SQL> shu immediate oracle$ lsnrctl stop oracle$ umask 022 && $ORACLE_HOME/bin/relink all root$ $ORACLE_HOME/root.sh
Lets start up and see what happened.
SQL> startup mount Database mounted. SQL> alter database open; Database altered. SQL> select id, svrname, dirname, nfsversion from v$dnfs_servers; no rows selected
And no DNFS! alert log is also missing the DNFS message:
Oracle instance running with ODM: Oracle Direct NFS ODM Library Version 6.0
Let shut it down and link DNFS back.
SQL> shu immediate oracle$ cd $ORACLE_HOME/rdbms/lib && make -f ins_rdbms.mk dnfs_on root$ $ORACLE_HOME/root.sh SQL> startup mount SQL> select id, svrname, dirname, nfsversion from v$dnfs_servers; ID SVRNAME DIRNAME NFSVERSION ---------- ---------- --------------- ---------------- 1 10.122.9.9 /pt101 NFSv3.0
And I have my precious DNFS back. So keep that in mind when you relink Oracle home binaries. Would be good to test if the same problem affects Unified Auditing.
ORA-01511, ORA-01141, ORA-01110, ORA-17503, ORA-17515 and ORA-06512 when executing dbms_dnfs.clonedb_renamefile
- Written by: ilmarkerm
- Category: Blog entry
- Published: October 27, 2014
This post is for those who google the errors and maybe it will help to save some time. I’ve been playing around with clonedb for some time now and every time I hit these errors it takes me some time to figure out what actually the problem is 🙂 The error messages are not really helpful at all. Maybe I’ll remember it now.
When creating a new clone database using clonedb then after creating the new controlfile you need to execute dbms_dnfs.clonedb_renamefile(sourcefile, deltafile) for each of the data files in the image copy (sourcefile) to create a file that will hold the changes done to this datafile (deltafile). For example if one of the data files in image copy is named /nfs/source/user_data.dbf and I want to store changes done to this file as /u02/db/delta/user_data.dbf then need to execute:
SQL> exec dbms_dnfs.clonedb_renamefile('/nfs/source/user_data.dbf', '/u02/db/delta/user_data.dbf');
Sometimes when I run it I get strange errors:
SQL> exec dbms_dnfs.clonedb_renamefile('/nfs/source/user_data.dbf', '/u02/db/delta/user_data.dbf'); ERROR at line 1: ORA-01511: error in renaming log/data files ORA-01141: error renaming data file 6 - new file '/u02/db/delta/user_data.dbf' not found ORA-01110: data file 6: '/nfs/source/user_data.dbf' ORA-17503: ksfdopn:1 Failed to open file /u02/db/delta/user_data.dbf ORA-17515: Creation of clonedb failed using snapshot file /nfs/source/user_data.dbf ORA-06512: at "SYS.X$DBMS_DNFS", line 10 ORA-06512: at line 2
This happens when clonedb init.ora parameter is FALSE (default). So before running dbms_dnfs.clonedb_renamefile make sure clonedb is set to true. If it is not, then change the parameter and bounce the database.
SQL> show parameter clonedb NAME TYPE VALUE ------------------------------------ ----------- ------- clonedb boolean FALSE SQL> alter system set clonedb=true scope=spfile; SQL> startup mount force
PS. Starting from 22.214.171.124 the deltafile does not need to be stored in NFS server (and accessed using dNFS) and can be a local file instead, but the problem remains and the error comes from 126.96.36.199.