Skip to main content

Troubleshooting Oracle Provisioning - Check Oracle notifications or debug hook (KBA1067)



While the provisioning job to create the virtual database (VDB) is running, click the Actions link in the upper-right corner of the main Delphix administrative console to view the list of running jobs.  Click on the entry for the provisioning job to expand and see the detailed steps within the running job...

Which step seems to be taking the longest amount of time?

If the description of the action step says "executing user-specified hook", then please diagnose the operation of the shell-script within the hook.  Please start with the documentation online here, and try debugging the shell-script outside of Delphix first to verify that it is operating correctly before embedding it within the hook.  If you are running a hook in an Oracle RAC environment, please be sure to understand how hooks operate in that environment.  When testing outside of Delphix, please be sure to emulate the environment within the hook by setting the proper UNIX/Linux environment variables correctly.

If the description of the action step mentions "Oracle", such as "recovering Oracle database" or "opening Oracle database", then more detailed information for understanding what is happening can be obtained by checking the Oracle database "alert.log" file.  Most often, this file exists under the "$ORACLE_BASE/diag" directory tree for the VDB on the target database host/server, and is named "alert_${ORACLE_SID}.log", as shown below...

$ echo $ORACLE_SID
$ find ${ORACLE_BASE} -name "alert_${ORACLE_SID}.log" -print

The UNIX/Linux "tail -f" command will show the most recent actions performed within the Oracle database.

If the Oracle database appears "hung" because new line entries are not appearing in the "alert.log" file, then please work with your Oracle database administrator or UNIX/Linux systems administrator to diagnose the cause of the hang.

Very often, displaying the tail of the "alert.log" file may show that the database instance for the VDB is processing a large number of redo logs during a roll-forward operation.  If that is the case, then the next steps in the workflow may help you understand why, and what can be done about it.