Posted by Gwen Shapira on Jun 1, 2010
This should have been the easiest task on my todo list: Install Oracle 10.2.0.3 EE standalone on a new Linux RHEL 5 server, later to be used as a standby for a production RAC system. This means 2 lines of “runinstall -silent …”, less than 5 minutes of DBA work and maybe 20 minutes of waiting. I did not expect to spend over 5 hours doing this.
Problems started when I discovered that I don’t have the 10.2.0.3 patchset and another patch that exists on production and should be installed on the standby. I had to wait for my Metalink credentials to be approved for this customer CSI before I could download the patches for them.
“Why don’t you just clone the software from production?” asked a helpful colleague.
Read the rest of this entry . . .
Posted by Balraj Chahal on Jul 4, 2008
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~
Explanation
Read the rest of this entry . . .
