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

Home -> Community -> Usenet -> c.d.o.server -> Re: moving oracle database 9 from another computer to another one

Re: moving oracle database 9 from another computer to another one

From: joel garry <joel-garry_at_home.com>
Date: Wed, 19 Dec 2007 16:06:40 -0800 (PST)
Message-ID: <7b16af68-f3c0-4f1e-91ad-e6c92ffebffb@i12g2000prf.googlegroups.com>


On Dec 19, 1:44 pm, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
> On Dec 19, 2:32 pm, noumian <n.nou..._at_gmail.com> wrote:
>
> > oracle version : 9.2.0.4
> > Os source : SUSE linux
> > Os destination ; SUSE linux
>
> I find it appalling that an OCP DBA needs to be told this information.

metoo. But hey, he needs to learn somehow. We can but hope this isn't a critical production upgrade. Or maybe we can hope that it is, and revel in the Schadenfreude.

>
> That being the case you clone your database manually by:
>
> Installing Oracle 9.2.0.4 on the destination machine
> Setting the proper Oracle environment variables on the destination
> machine
> Creating a controlfile script by issuing the 'alter database backup
> controlfile to trace;' command
> Shutting down the source database in normal or immediate mode
> Copying all of the files over (including the controlfile creation
> script, the init.ora or spfile.ora) to the destination machine in the
> same locations to make it easier on you
> Configuring and starting the listener on the destination machine
> Starting the database nomount on the destination machine
> Creating a new controlfile with the script
> Opening the database resetlogs
> Shutting down the cloned database
> Taking a cold backup of the newly cloned database
> Starting the cloned database
>
> You can also use RMAN to duplicate your database. Read about that
> here:
>
> http://download.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmcon...
>
> I would be VERY careful when doing any of this; I really believe you
> need a qualified (meaning EXPERIENCED) DBA to do this task, as even
> though you profess to be OCP you're not qualified (in my opinion) to
> undertake it.
>

I don't think enough information has been given to determine whether cloning or exp/imp would be more appropriate.

I think if the purpose is to replace a production machine with another production machine, exp/imp might be better, together with some thought about whether existing data should be finessed with pctfree manipulations. This would be especially true if the database has been around for a while without maintenance, having such features as dictionary managed tablespaces (where I would include LMT's that were upgraded in place from DMT's as really having DMT structure). The "do I forget something?" post would just need to be modified to create a new empty database, and transfer the exp file (and of course, do all the extent analysis, preferably creating tablespaces and tables separately from importing the data).

If the purpose is to create a test machine, clone away.

The bit in the OP about keeping the same directory structure is somehow bothering me, I'm not sure why. Is it OFA or damagement?

jg

--
@home.com is bogus.
"Hubristic pride" sounds like...  http://www.signonsandiego.com/uniontrib/20071213/news_lz1c13vices.html
Received on Wed Dec 19 2007 - 18:06:40 CST

Original text of this message

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