Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 8174 32 bit to 9204 64 big

RE: 8174 32 bit to 9204 64 big

Date: Sat, 3 Apr 2004 07:23:28 -0600
Message-ID: <0186754BC82DD511B5C600B0D0AAC4D607B0035A@EXCHMN3>


   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 Export could corrupt the dictionary. Now I just wonder what they are putting in the drinking water at Oracle Corp.

Dennis Williams
Lifetouch, Inc.
-----Original Message-----

[]On Behalf Of Tim Gorman Sent: Friday, April 02, 2004 11:11 PM
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:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at

Received on Sat Apr 03 2004 - 07:23:37 CST

Original text of this message