| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: 8174 32 bit to 9204 64 big
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_at_lifetouch.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Tim Gorman
Sent: Friday, April 02, 2004 11:11 PM
To: oracle-l_at_freelists.org
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.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.htmlReceived on Sat Apr 03 2004 - 07:23:37 CST
-----------------------------------------------------------------
 |
 |