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, 24 May 2001 17:02:51 -0700
Message-ID: <F001.0030E639.20010524164051@fatcity.com>

Jared,

I remember YOU doing this. If you explained the process to me at the time. I probably just nodded my head and said 'yes' a lot.

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com] On Behalf Of Jared Still Sent: Thursday, May 17, 2001 7:25 PM

To:     Multiple recipients of list ORACLE-L
Subject:        Re: Moving a database to a different machine


Steve,

Do you recall doing this about 5 years ago?

I recall doing this same procedure there, but without benefit of standby database.

Total downtime was less than 2 hours, and we did it during a slow period. ( probably Saturday night :(

Jared

On Thursday 17 May 2001 13:48, Steve McClure wrote:
> 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: Jared Still
  INET: jkstill_at_cybcon.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 24 2001 - 19:02:51 CDT

Original text of this message

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