RE: Database Migration and Upgrade across Servers ( from Solaris to HP)

Yechiel Adar wrote:
>
> I second Allen suggestion and just want to add the whenever possible I
> prefer to create a new database over upgrade in place.
> This way you have time to test your copy procedure and the application
> people can play with the new database without interfering with
> production.

I don't see the benefit. If you have a second set of equipment, you can just as easily test an upgrade in place on a copy of your database. The decision as to how to approach this is highly dependent upon database size, among other factors. If you are working with databases in the hundreds of G, you may discover that exporting the whole database and re-importing it takes far longer than is acceptable, given that the database can be just as safely upgraded in place in far less time. I continue to be puzzled by the seemingly widespread notion that it is generally a good idea to completely unload and reload your data just to achieve a software version upgrade. If you have other goals in mind, like reorganization or "defragmentation", tackle them independently.

In a previous thread on this topic, Brandon provided some good examples of when exp/imp might actually be a sound business decision:

• The testing/validation cycle for any change event at your organization is prohibitively onerous, so ironically you opt to be *less* cautious and bundle several changes (upgrade and reorg or migration) into a single event.
• The database is so tiny that it actually will take less time to complete a full export and import than to run catupgrd.sql.
• The database has never been reloaded since 7.3 or 8.0 and you are now on 10g or 11g and encountering bugs related to legacy block format or something like that.

Other than these examples, "upgrade by exp/imp when possible" is another one of those insidious Oracle rules of thumb that should be stamped out. Only do things for a reason!

Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net

--
http://www.freelists.org/webpage/oracle-l