Re: Sanity Check
Date: Sat, 11 Oct 2008 16:29:56 UT
Finn Jorgensen's suggestion is good. But in case you don't have standby, you can do the followiing. Replies embedded.
We have a database migration to new hardware tomorrow and this is something I was considering doing to save time tomorrow. I wanted to get a sanity check to see if I'm missing anything or have failed to consider anything.
1.) Restore prod database to the new machine (same name, same
2.) Shutdown prod database tomorrow and switch logfiles as part of the shutdown (shutdown trigger) to generate final archivelogs on old machine
3.) Copy archivelogs from old machine after shutdown to new machine
4.) Recover <new> prod database on new machine Shutdown the db on the new server, backup the controlfile, bring the controlfile and online logs from old server Skip step 5 below instead , startup mount with the broughtover controlfile, recover database (it will say media recovery complete)
alter database open (no need for resetlogs). I am assuming that you are recovering till the last archived redo log in step 4 using backup controlfile.
5.) Open <new> prod database on new machine with resetlogs 6.) Take a backup of <new> prod database Do I run any risk of losing transactions in the existing prod database?
You would need to bring the orapwSID, Wallet if any files. If you are using wallet donot forget to bring /update sqlnet.ora Other associated tasks would be to take care of oratab , permission of $OH/bin/extjob , $OH/rdbms/admin/externaljob.ora if you are using dbms_scheduler. If the clients are connecting hardcoded IP then they would need to update their tns as well. Take care of cname / alias for the server + plus anything that might be associated with your environment. You would need to bring in crontab / scripts too.