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

Touche :)

There is definitely value in Jeremiah's suggestion, but you must account for the incremental cost of extra testing, tuning, troubleshooting, etc. For example, let's say you're company's policy is to test 100 business-critical functions before implementing any major change and it takes 50 hours to do that testing. If you do the upgrade and migration separately, now you have to do 100 hours of testing instead of just 50, and this can be very frustrating to the users that have to do the testing. The DBA will also have to do two iterations of query tuning and troubleshooting. For example, if you upgrade on your current hardware, you may have to work through problems with bugs that only exist on your platform, but could've been avoided had you moved to the new hardware in one fell swoop. So, sometimes it may be preferable to consolidate such changes, assuming that the final destination environment is thoroughly tested prior to go-live. When problems come up on the new system/version, you're going to have to troubleshoot and fix them regardless of whether it was the upgrade or the migration that caused them so I prefer to just get it over with.

Metalink # 412271.1 has the details on the bug I mentioned that will crash your database if you do an in-place upgrade to 10.2.0.3. If you go to 10.2.0.4 you should be okay.

Regards,
Brandon

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