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

firstly I ought to say that I agree entirely with Jeremiah. In fact I'd go further and suggest that dbua be your first port of call ahead of any manual method. dbua will be aware of things you aren't and does do sensible checks and reminders that dbas can miss. Right, that said one for export/import, - should you be upgrading from 9 to 10 or higher and have millions of private synonyms an in place upgrade will fail either way. exp followed by selective imp and a rejig of the synonyms strategy works well.

On 05/08/2008, Jeremiah Wilton <jeremiah_at_ora-600.net> wrote:
> 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
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
http://www.freelists.org/webpage/oracle-l