Thursday, August 16, 2012

RMAN Cloning issues

I saw this issue few days back , it was related to some issue in 10.2.0.3 version database.We were doing point in time rman cloning from production to test.In the middle of the cloning it errored out saying that it is not able to create the control file.We created the control file manually including all the datafiles in the script.Then we followed the oracle support doc id  360962.1 to resume the rest of the cloning steps.

We restarted the cloning following the step 5 of the doc.

$ rman target / auxiliary sys/oracle@

RMAN> run { 

   set new name for datafile n to 'X';
   set until scn 1412841;
   recover clone database;
   alter clone database open resetlogs;
}


At the end of the script it was throwing error RMAN-00600 .It was strange why it was throwing this error.After sometime we noticed that this error was because we have not given the "Set newname for  datafile n to [newname]" in the script.Note that we are using the parameter db_file_name_convert in the parameter file of the test database.Still we changed it in the script and ran it again.This time set newname was taking almost 20 mins on each file .Looking at the primary database I found that it was doing a full table scan on X$KCCLH


SELECT RECID , STAMP , THREAD# , SEQUENCE# , FIRST_CHANGE# LOW_SCN , FIRST_TIME LOW_TIME , NEXT_CHANGE# NEXT_SCN , RESETLOGS_CHANGE# , RESETLOGS_TIME
FROM V$LOG_HISTORY
WHERE RECID BETWEEN :1 AND :1 AND RESETLOGS_TIME IS NOT NULL AND STAMP >= :1 ORDER BY RECID 




At the end of the script it had thrown the error again.This time something different.


RMAN-03002: failure of recover command at XX/XX/20XX 01:07:22
ORA-19870: error reading backup piece 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
ORA-19563: datafile header validation failed for file +XXXXXXXXXXXXXXXXXXXXXXXXXX


There are 2 errors .First one is saying the "error  reading from the backuppiece"and the second one saying "File header mismatch " .We verified that the backuppiece was valid by RMAN validate command but the second issue was still a mystery.

In my opinion instead of  "Set newname for  datafile n to [newname]" I should have used " Set newname for  clone datafile n to [newname]".

I didn't get the opportunity to try that option as it was kind of urgent so  we manually restored and applied the archivelogs  using following and the database was ready.

RMAN>recover database until logseq X;
Alter database open resetlogs;

But it doesn't feel good if you spent so much time in  doing the right thing and  something so simple is the workaround.This issue will remain a mystery for me as long as I am not able to reproduce this issue in test .
If anyone reading this gets the opportunity to try the "clone" clause let me know if that worked for you .

No comments: