Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: A special way of migration

Re: A special way of migration

From: Michael McMullen <>
Date: Tue, 27 Sep 2005 10:24:01 -0400
Message-ID: <BAY103-DAV14EF9779CE09CEC1C608D0A68A0@phx.gbl>

How come the production server isn't available during the export or it isn't safe?
It seems going the script way would require a whole lot more monitoring then an exp/imp. Think of all the hours spent writing/debugging/monitoring the code. Are your servers the same OS?
----- Original Message -----
From: <>
To: <>
Sent: Tuesday, September 27, 2005 10:10 AM Subject: A special way of migration

> Hi list,
> i have an unusal question i think, but i am curios about your meaning
> this.
> I am often in the situation to get a production database from an old
> db-server
> to a new one. In some cases i am also instructed to lift up the Oracle
> Version. Naturally i use export/import to get all the data of our
> application
> into the new database.
> Sometimes the databases are quite big (about 20 to 200 Gig), so the Import
> and
> some other stuff lasts long. The consequence is, of course, to do it at
> weekends or after buisness hours.
> So far so good. There is no problem so far, but i was thinking about
> another
> solution for this task.(maybe i am just lazy? ;-)
> Here is my idea.
> Write a package to get the application data via a database link into the
> new
> database. The easiest way is "create table ... as select * from
> ..._at_db_link"
> This is very fast, as my first tests have shown.
> After that, i get all Indexes via some dynamic SQL, the same with all
> of
> constraints. At last i get all defaults for the table columns also via
> dynamic SQL
> The advantage for me is, i can start one procedure, enjoy my weekend and
> just
> have to look for problems after everything is done. It seems to be safe
> the old production database, so, in worst case, we just have to cancel the
> installation of the new db-server, but the production database is still
> available.
> What did i miss? Where are the pitfalls?
> I started to write the package. It is working inside a test - scenario
> a
> small database.
> Some things are still missing. Views are not implemented now, also
> are not ready yet. Packages of the application are no problem, because
> are part of the installation of the application so i can install it after
> the
> process is done. if they are compiling without errors, it is also a good
> sign
> for the whole "migration" of the data because of the dependencies.
> Sequences are also not totally ready now.
> So, what is your opinion?
> Thx in advance
> Joerg
> --

Received on Tue Sep 27 2005 - 09:27:48 CDT

Original text of this message