Oracle Apps 11.5.9: Post-Clone Fails if DBA_JOBS Not Turned Off

Posted in: Technical Track

We recently had an issue with a client while cloning a huge database. The result was that we had to restore the whole database as the post-clone corrupted the existing database. Pain! It took another fourteen hours to restore.

This may help you to troubleshoot the issue.

/sbox/oracle/product/920/appsutil/clone/bin$ perl dbTier

Errors in the Alert.log after Clone failure

Completed: ALTER DATABASE ENABLE PUBLIC THREAD 3Shutting down instance: further logons disabled
Shutting down instance (normal)License high water mark = 5Mon Apr 14 14:49:00 2008

Errors in file /sbox/oracle/product/920/admin/Prod/bdump/sbox1_j001_2453612.trc:

ORA-12012: error on auto execute of job 16303
ORA-12008: error in materialized view refresh path
ORA-28112: failed to execute policy function
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 820
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 877
ORA-06512: at "SYS.DBMS_IREFRESH", line 683
ORA-06512: at "SYS.DBMS_REFRESH", line 195ORA-06512: at line 1~


The post-clone restarts the database a few times during the process. If DB jobs are scheduled, they don’t allow the database to shutdown, which corrupts the database and hence the clone fails.


After the database is copied over and you are ready to run the post-clone, perform the following:

  1. Start the database.
  2. Spool the results of the following query to an SQL file.
    SQL> select 'exec dbms_job.next_date( ' || job || ' , sysdate+7);' from user_jobs;
  3. Execute the spooled SQL file.

This will delay all the scheduled dba jobs which otherwise prevent DB shutdown during the post-clone steps.



Want to talk with an expert? Schedule a call with our team to get the conversation started.

6 Comments. Leave new

Balraj ,

Thank q so much for your blog , it is quite informative abt delaying the scheduled jobs for a while during the cloning process , but i have small confusion here if we are cloning with rapidclone , we run as a part of post-clone on the target system but not on the source system (i.e existing database) , then how come post-clone will corrupt the source system (existing DB), and also you have mentioned during the post-clone DB will restart few times , which DB it is, is it source or target, couls you be more precise and elaborate the whole process taking the two DB’s as example (like PROD and TEST).



I’m about to work on RAC for the first time and just concerned about the issues. Do you provide some training on RAC.


Balraj Chahal
April 29, 2009 11:33 am

Hi MAdy,

Sorry for delayed reply. The destination is corrupted during the postclone as the appsutil doesnt have the entire information of the datafiles that exist in the backup , so while rapidclone tries to open the database with the RESETLOGS , it doesnt find all files in the appsutil corresponding to information in the SYSTEM tablespace – hence the database is orrupted

TEST(the one you are cloning will start/shutdown few times during the clone

— Hope that helps !!

Best Regards,
Balraj S Chahal

Balraj Chahal
April 29, 2009 11:42 am


In nutshell , we are not doing anything on the source – so the corruption occurs on the Destination (your new environment for clone)

Best Regards,
Balraj S


Hi Balraj,
I wanted to know if setting job_queue_processes=0 helps avoid this situation?

Balraj Chahal
April 30, 2009 11:53 am


It didnt help for me. Had to turn of the DBA_JOBs in the database

Best Regards


Leave a Reply

Your email address will not be published. Required fields are marked *