RE: Lost one in Migration

  • From: John Kanagaraj <john.kanagaraj@xxxxxxx>
  • To: "'rgramolini@xxxxxxxxxxxxxxx'" <rgramolini@xxxxxxxxxxxxxxx>, Michael.Kline@xxxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 28 Apr 2005 16:36:55 -0700

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

Other related posts: