Skip to main content

ORA-01503: CREATE CONTROLFILE failed Encountered with ORA-00600 During VDB Provision or Refresh using dNFS (KBA9021)




KBA# 9021



During VDB provsion or refresh, the job may fail with the event Failed to recreate control file.  


This behavior is only expected to be encountered with Oracle, with Oracle Direct NFS (dNFS).

Applicable Delphix Versions

Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases




Reviewing the Oracle alert log for the VDB, or the auxiliary CDB created during recovery, ORA-01503 and ORA-00600 may be encountered with the following signature (in the instance ORA-00600 internal errors are encountered, the distinct arguments are used to further correlate events):

Thu Mar 17 14:22:04 2022
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Errors in file /u02/app/oracle/diag/rdbms/cxvjrfuvmnd/CXVJRFUvmnd/trace/CXVJRFUvmnd_ora_177613.trc  (incident=12721) (PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [ksfd_odmcrt3], [10008], [], [], [], [], [], [], [], [], [], []
Incident details in: /u02/app/oracle/diag/rdbms/cxvjrfuvmnd/CXVJRFUvmnd/incident/incdir_12721/CXVJRFUvmnd_ora_177613_i12721.trc

Additionally, ORA-17500 events may also be logged, but this has not been observed consistently.


Further investigation with Oracle has correlated this behavior with a known issue, detailed in MOS under Bug 20720667  Operations over remounted dNFS raise ORA-17500 or write files in old mountpoint (linked below).

In addition to application of the patch referenced, alternative workaround are offered such as:

  • Restarting the database
  • Use a different NFS mount point (mount base, in VDB provision context)
  • Disable Direct NFS (dNFS)

As the database instance started up is distinct in Delphix VDB recovery, the suggested restart of the affected instance is not applicable, but the core issue is related to mount details in SGA, presumably shutting down ALL database instances running on the affected host and restarting may successfully work around this behavior.

Ultimately, Oracle Support should be engaged when this behavior is encountered, and the alert log as well as trace files referenced in the alert log provided for further review.



Related Articles

The following articles may provide more information or related information to this article: