RE: Database Migration and Upgrade across Servers ( from Solaris to HP)
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <jeremiah@xxxxxxxxxxx>, <oratips@xxxxxxxxx>, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 31 Jul 2008 15:41:20 -0700
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
