Re: RE: 8174 32 bit to 9204 64 big
- From: <solbeach@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sat, 3 Apr 2004 9:52:14 -0500
> From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
> Tim
> I think this is a very important issue for all of us. An upgrade offers
> the potential to corrupt a database even in the best of circumstances, and
> we should strive to reduce that risk.
IMO, bugs are bugs and software is too dumb to know whether
it is being invoked from an installation script or from an
upgrade script. For example is CATPROC.SQL has a bug in it,
bad things will happen within the Data Dictionary regardless
of doing a fresh install or an upgrade/migration. In an
ideal world both a fresh installation & import or an upgrade
should get you to the same end condition. In the past I've
avoided using GUI wizards because they were to much black
magic for me. However I recently used DBUA to upgrade a DB
from V7.3.4.5 to V9.2.0.4 painlessly. I had done about a
dozen test upgrades before doing the actual production DB
for real and was completely confident that no issues would
result. The upgrade was 100% successful (& painless). I'll
always take the path which requires less time & effort as
long as I am confident that I'll be successful. Needless
to say, prior to statring DBUA I was sure I has a solid
backup in case Murphy showed up to ruin me day. Actually
this database went from Solaris V2.6 (32-bit) to Solaris 9
(64-bit) running 64-bit Oracle V9.2.0.4.
For once Oracle got something right!
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
- » Re: RE: 8174 32 bit to 9204 64 big
