Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Suggestions please

Re: Suggestions please

From: Brian Peasland <>
Date: Mon, 19 Apr 2004 15:39:27 GMT
Message-ID: <>

"Howard J. Rogers" wrote:
> Scenario: two networked servers. One server currently houses a 9i
> database. Database is to be moved to the new server. (Both servers are
> Solaris). Database is 24x7, so downtime must be minimal. Database is
> only 20GB in size.
> The two servers cannot share storage of any kind, so my original idea of
> creating new tablespaces within the same database but on the new box's
> storage and then moving tables/indexes across to the new tablespaces is
> not a go-er (unless maybe an NFS mount would do the trick...??). For
> the same reason, my other idea of using dbms_redefinition to move the
> data across and incurring minimal table locking is not a flyer.
> There is a possibility of creating a new database on the new server,
> populating it with empty copies of the source tables, and then
> populating the new tables via dblinks... but the concern is that clients
> will modify data in the source tables as the move takes place (thanks to
> the 24x7 ruke0, and therefore another possibility has been discussed of
> setting up replication between the two databases to capture
> post-initial-setup DML... but replication to handle the move of a 20GB
> database strikes me as absurd.
> Basically, I'm just casting around for suggestions as to how you would
> approach the issue.
> Anyone got any timings on a 20GB export and import?
> Regards
How about using Transportable Tablespaces? You could crossmount a filesystem and then transport the datafiles to the new server that way. Or, you could even use rcp (or scp) to copy the datafiles. The most time consuming task in this operation would be to copy the datafiles to the new server. Obviously plugging them in won't take too long, especially if you script the whole thing before you start. And you'll need to move non-segment objects over with SQL, but DBMS_METADATA should help there...



Brian Peasland

Remove the "remove_spam." from the email address to email me.

"I can give it to you cheap, quick, and good. Now pick two out of
 the three"
Received on Mon Apr 19 2004 - 10:39:27 CDT

Original text of this message