Re: move database to new server/directory

Charles Hooper wrote:
> >
> > Never, never, never export.....It's now not the same db any more...
> > You've altered your prod data and now own the problem if there are any
> > issues.
> >
> > I'm happy that it worked for you though.
> > Cheers....
>
> I disagree regarding the statement "Never, never, never export". If
> the old database server was running some variant of 8i, 9i, or 10.1,
> the RMAN method would not move the database to the new server. One of
> the advantages of using export and import is to perform repeated
> testing of Oracle upgrades, and/or application upgrades. For instance,
> if I was running Oracle 8.1.7.3 on an old server, and wanted to test
> application compatibility with Oracle 10.2.0.2, exporting from the old
> server and importing into the new server is perfectly acceptable. The
> export/import process also allows database reconfiguration changes, and
> testing those changes without risking harm to the production database -
> such changes may be moving to a different character set to support XML
> data (watch out for problems with this change), moving to locally
> managed tablespaces, changing file location, changing database SID
> name, etc. Yes, RMAN or other commands can be used to help with some
> of these tasks, but it is very easy to script an export, create
> tablespace, and import.

Export/import has worked consistently ( and will continue to work in the future ) in a variety of tasks for as long as I have been working with oracle. Obviously there are improvements in 10g but the old functionality for compatibility will be around for a long time.

You are right on target Mr. Hooper.

>
> I do agree that you should not export, delete the database, and import
> to "improve" performance. There are great risks with this practice,
> and it has been covered from time to time on asktom.oracle.com.

This is a technique? Not familiar with that flawed approach. Received on Fri Nov 17 2006 - 07:15:22 CST