Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Moving a database to a different machine

RE: Moving a database to a different machine

From: Steve McClure <steve_at_pactr.com>
Date: Thu, 17 May 2001 12:34:52 -0700
Message-ID: <F001.00306C0C.20010517124851@fatcity.com> 






Koivu, Lisa said


"A word of warning, and you probably already know this: you can't have both
databases open at the same time or you will end up with incompatible archive
logs and control files. Good luck !"




hehe I did know, but upon reading your warning it still frightened me for a
moment. Because I was planning to do this one time prior to the move to
allow for testing. Therefore having both databases up and running at the
same time on the two different machines. I know I will have to do the
migration again when we actually move, so that the database(s) will recover
properly. Oh and thanks for the tip about just moving the arc/redo/control
files back to the production machine to resynch the DBs. That will save me
from some tedium on moving day.


Steve McClure


-----Original Message-----


Sent: Thursday, May 17, 2001 11:47 AM


To: 'ORACLE-L_at_fatcity.com'; 'steve_at_pactr.com'



Hi Steve,


I used this same strategy with a migration last month. It minimized our
database related downtime to 30 minutes (and then they unplugged the
symmetrix and the app server was down for 12 hours. Oh well)
This plan will work. Once your production machine is physically moved and
set up, you can do the reverse to apply changes to the prod database without
copying over the entire database from dev:
Starting with production database down, the following steps will bring prod
up to date:

1. Shutdown dev
2. Copy over control files/redo logs/arc logs
3. Start up prod
4. Initiate recovery




Voila. Slick.


A word of warning, and you probably already know this: you can't have both
databases open at the same time or you will end up with incompatible archive
logs and control files. Good luck !



Lisa Rutland Koivu


Oracle Database Administrator


Certified Self-Important Database Deity


Slayer of Unix Administrators


Wanton Kickboxing Goddess


lkoivu_at_qode.com



NeoMedia



2201 Second St., Suite 600


Fort Myers, FL 33901, USA


Phone: 941-337-3434


Fax: 941-337-3668

www.neom.com <http://www.neom.com>
www.paperclick.com <http://www.paperclick.com>
www.qode.com <http://www.qode.com>





P a p e r C l i c k . c o m <http://www.paperclick.com/home.htm>
Enter Your PaperClick Code Here!



-----Original Message-----


Sent: Thursday, May 17, 2001 2:26 PM


To: Multiple recipients of list ORACLE-L
Allright,


We are physically moving our office, and have an OLTP application that needs
to be up and running with minimal downtime. The current plan is to use the
development computer as the production platform while the Primary computer
is physically moved to the new location. The development system was the
production system about 6 months ago, so it will not be under too much
strain.


I have completely duplicated the filesystems of the Primary machine on the
development box.


This is my plan. Please comment if there is an obviously better way. Oh
the database is version 7.3.4


1.Put the tablespaces of the production database in backup mode.
2.Copy datafiles across the network to the "development" machine. Approx 3
GB

3.Take the production tablespaces out of backup mode.
4.Force a log switch.(Habit I guess)
5.wait until the production system is brought down.
6.move the control files and redo logs to the development system
7.move the initSID.ora and configSID.ora files.
8.edit configSID.ora to change the host associated to Listener.
9.fire up svrmgrl, and recover the database.


10.change the tnsnames on the client systems to point to the development
machine.


Of course. This needs to be tested to some degree first. And we(well
management at least) don't want to bring the production machine down to roll
the databases forward together just for a test. I can use make a backup
control file for use during recovery, and move the curently offline redo
logs. I am not sure what to do about the most current redo log in this
case. I have played with backup and recovery, but not this scenario. I
don't currently have my copy of the Velpuri backup and recovery handbook at
hand(Loaned it to a colleague). So I am bouncing this off of you folks
while I ponder this until I retrieve my backup and recovery bible.
Any Comments are appreciated.


Thanks,


Steve McClure




--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve McClure
INET: steve_at_pactr.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from). You may

also send the HELP command for other information (like subscribing


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Steve McClure
  INET: steve_at_pactr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L


(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).


Received on Thu May 17 2001 - 14:34:52 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US