RE: 8174 32 bit to 9204 64 big
- From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 3 Apr 2004 07:23:28 -0600
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.
I would be curious to know more about your logic. I always appreciate
someone that forces me to examine assumptions I have held for some time. I
agree that Upgrade is faster and that export/import is not practical past a
certain database size and downtime window. And I have obviously performed
both methods many times and really haven't had any problems either way. And
for the benefit of any novices reading this, with either path you must
create a test database and apply the same steps you will perform on
production.
I think the root of my concern with the upgrade stems from two factors.
The first is my fear of dictionary corruption since that can produce an
unrecoverable database.
The second is having been a developer at a software vendor, a desire to
stick with the most well-tested portions of the code. In testing Oracle 10g,
the developers and testers at Oracle corporation will create thousands and
thousands of databases. How many of those will be upgrades? By far the
minority, I'm sure. And while there are just a few combinations of features
for a freshly created database, the combinations of features for an upgraded
database are probably infinite. My concern is that my database will have
some combination of features that was not part of the upgrade tests by
Oracle's QA department, and the possibility this will create corruption that
goes undetected until after my database is well back into production.
With a freshly created database, the database is created with all-new
features. For example, in Oracle9i the system tablespace is LMT by default.
Does the upgrade convert the system tablespace to LMT? Don't know, didn't
happen to upgrade a database from 8i to 9i because we were buying new
hardware then. This is probably not a big issue per se, just an example.
Over the years I have observed many more Oracle Bug reports on the
upgrade process corrupting databases than import corrupting databases.
Anyway that was my thinking until I discovered that 9.2.0.1 Export could
corrupt the dictionary. Now I just wonder what they are putting in the
drinking water at Oracle Corp.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Tim Gorman
Sent: Friday, April 02, 2004 11:11 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: 8174 32 bit to 9204 64 big
If change of platforms is not part of the task, then I strongly disagree.
Export/Import is riskier and slower.
Upgrading the software and performing the 32-64 bit update according to the
plentiful documentation on Metalink is faster and safer than exporting and
importing. It's really the only viable option for a database of any size.
----------------------------------------------------------------
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:
