Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Lost one in Migration

RE: Lost one in Migration

From: John Kanagaraj <>
Date: Thu, 28 Apr 2005 16:36:55 -0700
Message-ID: <>


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!

John Kanagaraj <><
DB Soft Inc
Phone: 408-970-7002 (W) - Manuals for DBAs (English only) - Manual for Life (in English, Deutsch, French, Italian, Spanish, Portugese, Turkish,...)

-----Original Message-----
From: [] On Behalf Of Ruth Gramolini
Sent: Thursday, April 28, 2005 11:51 AM
To:; 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 ( 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.


-----Original Message-----
[]On Behalf Of Kline.Michael Sent: Thursday, April 28, 2005 1:49 PM
Subject: Lost one in Migration

Going from to
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], [], [], [], [], [], [], [] 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
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], [], [], [], [], [], [], []

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

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]

Received on Thu Apr 28 2005 - 19:41:27 CDT

Original text of this message