ORA-01511, ORA-01141, ORA-01110, ORA-17503, ORA-17515 and ORA-06512 when executing dbms_dnfs.clonedb_renamefile
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 188.8.131.52 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 184.108.40.206.