How do I clone a database but still apply old archivelogs? Getting ORA-1223

Question

Hi,
I'm doing a clone from PROD to DEV in 9.2.0.6 for 11.5.10.2 on Solaris 9. I worked through many issues, such as copying the files, changing the init<SID>.ora to the new DEV values, re-editing all of the env files with the new SID on the new (target) machine name, etc.
The data is about 2 weeks old and so I was hoping to not only recover this database during the clone, but ALSO roll forward, applying all of the old archive logs to date. (Nothing changed in the middle tier save for a few
paramaters in the xml file which I've already edited).
Normally when I'm cloning -- I do it with fresh/recent data files so I don't care about reseting the archivelogs, I just reset them and say si-a-nerra!
But.... now I am trying to both change the database name (SID) and apply a bunch of archvie logs (about 2 weeks worth). Note: I also recreate the control file as part of my whole process too.
Here's the problem I am having -- after doing a startup nomount in the new location (with my new environment files, data files, etc all in place) and
then doing @recreate.sql (which is the edited control file script from the 'backup controlfile to trace' on prod) I am getting this message:
SQL> @recreate.sql
CREATE CONTROLFILE SET DATABASE "DEV11i" NORESETLOGS
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01223: RESETLOGS must be specified to set a new database name
- well OK this message makes sense to me - yes I could easily just keep the new name and say RESETLOGS, but I don't want to do this !!! I want to set the new name for the clone, and keep the logs unset so that I can then recover until cancel, applying my 2 weeks worth of logs.
- What is the solution? Do I have to just bite the bullet and do RESETLOGS instead? (and in effect make my recovery practice seperate from my current cloning tasks)
- Or should I change everything back to the old (original name) LIVE11i (for Prod), including the env files, data files etc .. on the new (target) machine.., recover the database completely (maybe even disconnect it from the network and rename the (target) machine to the old prod server name), and then do another whole procedure (which I'd have to find - but I know it's similar) for changing the SID...
Please help. Thanks in advance! Marvin.
Message was edited by:
umfan866

Answer 1

Oviwan,
Because of getting the error message, the recreate controlfile has not
gone through, thus I have not yet reset the logs.
What I'm going to do for now is in fact change the script to SET
the new name for DEV11i and RESET the logs, just to test my clone. The
data will be 2 weeks out of date, but I'll have verified that my files from tape
work (these files had come of the tape, and are now 2 weeks old).
To make the DB fresher, I can just re-clone with RESET using last night's
hot backup from PROD. That'll freshen DEV's files up no problem.
I had wanted to test all these archive logs and see if they apply nicely,
but I'll just have do that on a separate box (disconnected from the network)
where I keep the DB name and machine name the same as prod.
Thanks for your help! Marvin.