Re: Sanity Check
Date: Sat, 11 Oct 2008 16:29:56 UT
Message-Id: <1223742596.11375.1278754597@webmail.messagingengine.com>
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
paths) tonight
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.
HTH
GovindanK
-- http://www.freelists.org/webpage/oracle-lReceived on Sat Oct 11 2008 - 11:29:56 CDT