| 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: Lost one in Migration
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Ruth Gramolini
Sent: Thursday, April 28, 2005 11:51 AM
To: Michael.Kline_at_SunTrust.com; oracle-l_at_freelists.org
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Kline.Michael
Sent: Thursday, April 28, 2005 1:49 PM
To: oracle-l_at_freelists.org
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 bytesDatabase mounted.
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_at_suntrust.com
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Apr 28 2005 - 19:41:27 CDT
 |
 |