Filed 04-DEC-2000
Product Oracle Server - Enterprise Edition V7 Product Version  8.1.6.1 
Platform Sun Solaris V2 Sparc Platform Version No Data 
RDBMS Version 8.1.6.1 Affects Platforms  Generic 
Problem statement:

ORA-6000 [4137] ERROR ENCOUNTERED WHILE RECOVERING TRANSACTION 
--------------------------------------------------------------------------------


The following was found in the alert log of the database. It appears very 
often.....
Mon Dec  4 17:54:48 2000
Errors in file /oracle/db/buza/bdump/buza_smon_23456.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Mon Dec  4 17:54:50 2000
ORACLE Instance buza (pid = 6) - Error 600 encountered while recovering 
transaction (5, 93).
Mon Dec  4 17:54:50 2000


If I go into SQL*Plus as sys, I can find out the following....

 US# RBSNAME    STATUS$ ROLLSTAT FILESTA FILENAME
---- ------- ---------- -------- ------- ------------------------------
   0 SYSTEM           3 ONLINE   SYSTEM  /d10/dbf/buza/system01.dbf
   1 MRCRBS1          2          ONLINE  /d10/dbf/buza/rbs02.dbf
   2 R01              3 ONLINE   ONLINE  /d10/dbf/buza/rbs01.dbf
   3 R02              3 ONLINE   ONLINE  /d10/dbf/buza/rbs01.dbf
   4 R03              3 ONLINE   ONLINE  /d10/dbf/buza/rbs01.dbf
   5 R04              3 ONLINE   ONLINE  /d10/dbf/buza/rbs01.dbf
   6 MRCRBS2          2          ONLINE  /d10/dbf/buza/rbs02.dbf


All of the above rollbacks have no active transactions, except 

  1  SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
  2                   KTUXESTA Status,
  3                   KTUXECFL Flags
  4              FROM x$ktuxe
  5             WHERE ktuxesta!='INACTIVE'
  6*              AND ktuxeusn=5
SQL> /

  KTUXEUSN   KTUXESLT   KTUXESQN STATUS  FLAGS
---------- ---------- ---------- ------- ------------------------
         5         93      88973 ACTIVE  DEAD

Have tried bringing the rollbacks off-line and on-line, but has not fixed the 
above transaction.
.
If Block-5 is corrupt Oracle cannot know if any transactions are active or not 
from that rollback segment. If we do not know if the transactions are active 
or not we cannot roll out any that were active. This potentially leaves us 
with a large number of active transactions that cannot be rolled out.
.
.
Tried shutting down the database and starting in exlusive mode, then took the 
tablespaces off-line and back on-line, then I did a shutdown and normal 
statup. Still I have the same problem.
.
It seems SMON is not recovering the information in the "corrupted" rollback 
segment.     
.
Can you offer any help?
I have placed the the trace file in the following location
ess30:/bug/bug1528312/buza_smon_23456.trc
 SMON is trying to recover the dead transaction with xid 0x0005.05d.00015b8d, 
 but the undo block that the transaction table must be pointing to is owned by 
 xid 0x0005.015.00015b96. I don't see a dump of the rollback segment header 
 with the transaction table in the trace file. Please provide one.
 Also, please provide the alert log. Make sure it contains the info from before 
 this ORA-600 was first reported. 
 Were any OS errors reported such as I/O errors or disk errors before the error 
 started happening?
 Were any Oracle trace files generated before this error started happening? If 
 so, please provide them.
 Do you have archived redo logs going back to when the error started happening? 
 If so, then please dump the archived redo logs for block 0x178046a7 (94/18087) 
 and the rollback segment header.
 We won't be able to determine what changes the dead transaction made without 
 redo log dumps, so it may not be possible to recover this database. You may 
 have to mark the rollback segment as corrupted in init.ora, export your data, 
 recreate the database, and import your data. Then there may still be 
 inconsistencies in your data, so you will have to validate it.
 Suspending while we wait for the info.