Twitter Updates 2.2.1: FeedWitter

Monday, December 5, 2011

ORA-600 [kck_rls_check must use (11,0,0,0,0) or lower] during db duplicate

I just wanted to share this since when searching for this error, I didn't find out how to get around around it.

BACKGROUND -  I am running a dbdupliate through grid control for a 11.2.0.2 database.  Everytime it goes to create the standby database the copy fails with following errors in the log

 connected to auxiliary database (not started)
  
  released channel: tgt1
  
  released channel: tgt2
  
  RMAN-00571: ===========================================================
  
  RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
  
  RMAN-00571: ===========================================================
  
  RMAN-03002: failure of Duplicate Db command at 12/03/2011 23:49:25
  
  RMAN-05501: aborting duplication of target database
  
  RMAN-03015: error occurred in stored script Memory Script
  
  RMAN-04014: startup failed: ORA-00600: internal error code, arguments: [kck_rls_check must use (11,0,0,0,0) or lower], [kdt.c], [9576], [11.2.0.2.0], [], [], [], [], [], [], [], []
  
  RMAN-04017: startup error description: ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
  


I was finally able to get around it... The bug has to do with compression compatibility and the metalink note on this bug says to do

alter system  set "_compression_compatibility"="11.2.0";

The problem is that this needs to be done on the NEW copy of your database.. I was able to do this by setting up a script that runs

export ORACLE_SID=<>
sqlplus "/ as sysdate" @setparm
sleep 1
sqlplus "/ as sysdate" @setparm

sleep 1
..
..




cat setpar.sql
>    alter system set "_compression_compatibility"="11.2.0";
>    exit



I let this run a couple of thousand of those sqlplus/sleep entries on the new database servers.  within about 5 minutes, it was able to appropriately set the init parameter during the duplicate process and continue on normally.

If you see this error during your dbduplicate that is the best way to handle it..








No comments:

Post a Comment