Mike/Ruth, This is a classic one when upgrading from 8.1. to 9.2 (or 9.0 for that matter). You have to be VEWY VEWY VEWY careful with COMPATIBLE. It SHOULD be at 8.1.7 for the upgrade. This is because of the difference in Redo log format between 8.1.7 and 9.2 (or 9.0) which I think was introduced because of LSB support. The other parameter that you need to be careful about is "_system_trig_enabled". Set this to FALSE (along with COMPATIBLE = 8.1.7) until well after all the work is done and you are ready to release to the user. This will disable ORA-3113 errors crashing your instance at startup because the Java VM hasn't been installed and Oracle snuck in a Java based Database Startup trigger. And when compatible is set to anything other than 8.1.7, it stamps this in redo and it WILL NOT be possible to go back. I am talking fresh from retrieving a 250 Gb database from backup working 36 hours that went sour because of an issue related to this combination and the fact that the DBA (me!) mistakenly ran a CREATE UNDO when compatible was still at 8.1.7 but the command failed after creating a mess. I would suggest going to the backup and starting again. Don't fiddle around with the underscore parameter - it won't work on account of the redo difference - sorry! Hth, John Kanagaraj <>< DB Soft Inc Phone: 408-970-7002 (W) http://tahiti.oracle.com - Manuals for DBAs (English only) http://www.bibleserver.com - Manual for Life (in English, Deutsch, French, Italian, Spanish, Portugese, Turkish,...) -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ruth Gramolini Sent: Thursday, April 28, 2005 11:51 AM To: Michael.Kline@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: RE: Lost one in Migration I was told by Oracel Support to just change the compatible setting and then the ananlyst said "Oops' when it didn't work. I couldn't continue it took about a week to get it back. No one knew what to do. They all said "That isn't good!" We had already dismantled the old servers (32 bit) and reconfigured the new 64 bit servers we had to get a workaround to make the old version (8.0.6.3) work so we could do another recovery and try again. That trace that they say works to overcome the problem doesn't work. If you can do a restore back to the 8.1.7 version you can just take out the compatible parameter and try again. If not, you may be in for a long haul. If I can do anything else to help you, please let me know. Ruth -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Kline.Michael Sent: Thursday, April 28, 2005 1:49 PM To: oracle-l@xxxxxxxxxxxxx Subject: Lost one in Migration HPUX Going from 8.1.7.4 to 9.2.0.4. I and another DBA have just about exhausted our things to try. I had a compatible='9.2.0' in the init.ora for the 9i migration. You can't do this, but must set it AFTER the migration. I had obtained a copy of the init.ora from a working Version 9 and went over the lines one by one comparing them to "PFTST" to make the version 9 init.ora. Now I get the stuff below. I've tried using: _allow_resetlogs_corruption=TRUE EVENT = "10619 trace name context forever, level 1" Both of which were mentioned as ways to get around the problem. You would think they'd test for that "invalid at this point" setting. I've saved off the export, just in case. The log gives me this: alter database open resetlogs Thu Apr 28 11:37:45 2005 RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 1670398987 Resetting resetlogs activation ID 3053850856 (0xb60610e8) Thu Apr 28 11:41:26 2005 Errors in file /u001/app/oracle/admin/PFTST/udump/pftst_ora_12463.trc: ORA-00600: internal error code, arguments: [2765], [9.2.0.0.0], [], [], [], [], [], [] ORA-600 signalled during: alter database open resetlogs... Thu Apr 28 11:42:47 2005 Shutting down instance: further logons disabled Shutting down instance (immediate) License high water mark = 2 Thu Apr 28 11:42:47 2005 ALTER DATABASE CLOSE NORMAL ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL... Thu Apr 28 11:42:47 2005 ALTER DATABASE DISMOUNT Completed: ALTER DATABASE DISMOUNT ARCH: Archiving is disabled Shutting down archive processes Archiving is disabled Archive process shutdown avoided: 0 active ARCH: Archiving is disabled Shutting down archive processes Archiving is disabled Archive process shutdown avoided: 0 active SQL> startup mount ORACLE instance started. Total System Global Area 2158983784 bytes Fixed Size 739944 bytes Variable Size 1610612736 bytes Database Buffers 536870912 bytes Redo Buffers 10760192 bytes Database mounted. SQL> alter database open 2 / alter database open * ERROR at line 1: ORA-01589: must use RESETLOGS or NORESETLOGS option for database open SQL> alter database open noresetlogs; alter database open noresetlogs * ERROR at line 1: ORA-01588: must use RESETLOGS option for database open SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-00600: internal error code, arguments: [2765], [9.2.0.0.0], [], [], [], [], [], [] SQL> shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> exit Michael Kline Database Administration SunTrust Technology Center 1030 Wilmer Avenue Richmond, Virginia 23227 Outside 804.261.9446 STNet 643.9446 Cell 804.744.1545 michael.kline@xxxxxxxxxxxx ************************************************ The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. [ST:A234] ************************************************ -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l