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 adcfgclone.pl 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:
- Start the database.
- Spool the results of the following query to an SQL file.
SQL> select 'exec dbms_job.next_date( ' || job || ' , sysdate+7);' from user_jobs;
- Execute the spooled SQL file.
This will delay all the scheduled dba jobs which otherwise prevent DB shutdown during the post-clone steps.