Have you considered using transportable tablespaces instead? Note
291024.1 (Compatibility and New Features when Transporting Tablespaces
with Export and Import) would be a starting point.
Bob Stauffer
DBA
D&E Communications
Ephrata, PA, USA
717-738-8737
rstauffer_at_decommunications.com
________________________________
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Robyn
Sent: Friday, August 17, 2007 09:57
To: oracle-l
Subject: upgrades, conversions and ora-600's! oh my!
Hello all ...
I'm working on an upgrade from 9.2.0.8 to 10.2.0.2 with multiple interim
patches (version and patch level required by SAP). I'm consistently
hitting errors in the upgrade process in different copies of the
database that, per support, are related to a prior 32 bit to 64 bit
conversion, although just to make it interesting, the errors manifest
slightly differently in different databases. I think the 64 bit
conversion occurred while the database was on version 8.1.7, and
upgrades to 9i and subsequent patchsets reported no errors.
Working with support, I've implemented patches and workarounds,
including editing several of the catalog creation scripts. By applying
a patch and removing the XDB component in cpmigdb.sql, we're able to get
the upgrade process to complete without errors, the registry is valid
and there are no additional invalid objects. However, installing XDB
after the fact results in more ORA-600s so I'm still working with
support to figure out the XDB install.
I've testing multiple copies on both HP-UX and HP Intanium but have not
upgrade any of the *real* test database because my comfort level with
the resulting database just isn't there yet. Has anyone run into
similar issues after a 32 bit to 64 bit conversion? Were you able to
resolve them and how did you determine the structure is clean? As I
understand it, there is the potential with this issue to get a valid
report from the registry and still have an underlying issue, and I want
to be certain the upgrade will be clean before running it even the real
test system. One option that has been presented is completely
recreating the databases, but production is about 1.8 TB and rebuilding
would be a huge and expensive effort.
These are samples of the errors I was getting; I've already pulled all
the docs from Metalink so I'm aware of the various workarounds. Just
wondering how many others have seen similar issues and how they regained
confidence in the core structure. I've got a big server and 3 database
copies staged and backed up right up to the catupgrd.sql step, so I can
restore and retest to my heart's content if there's another variant to
try.
tia ... Robyn
Error samples:
ORA-00600: internal error code, arguments: [17069],
[0xC0000002458F74C8], [], [], [], [], [], [] (resolved with the patch
and workaround)
OCI-21500: internal error code, arguments: [koxsihread1], [0], [0], [4],
[], [], [], [] (with a call stack trace when utlrp is run the first
time after the upgrade)
ORA-00600: internal error code, arguments: [kocgpn129], [2], [], [], [],
[],[], [] (multiple times when attempting to install XDB)
**DISCLAIMER
This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business.
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Aug 17 2007 - 10:31:06 CDT
