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@xxxxxxxxxxxxxxxxxxxx ________________________________ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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 184.108.40.206 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: , [0xC0000002458F74C8], , , , , ,  (resolved with the patch and workaround) OCI-21500: internal error code, arguments: [koxsihread1], , , , , , ,  (with a call stack trace when utlrp is run the first time after the upgrade) ORA-00600: internal error code, arguments: [kocgpn129], , , , , ,,  (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.