一套Linux上的10.2.0.4系统在异常恢复后(使用_allow_resetlogs_corruption隐藏参数打开后遭遇ORA-00600:[40xx]相关的内部错误，创建并切换到了新的撤销表空间上)出现ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []内部错误，当该非内部错误(non-fatal)出现100次以上时会在告警日志alert.log中出现记录。 并有可能导致实例crash,具体日志如下:

Errors in file /s01/10gdb/admin/clinica/bdump/clinica_smon_21463.trc:
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Tue Jan  4 23:13:19 2011
Non-fatal internal error happenned while SMON was doing logging scn->time mapping.
SMON encountered 1 out of maximum 100 non-fatal internal errors.clinica_smon_21463.trc:
Dump of buffer cache at level 4 for tsn=1, rdba=8388633
BH (0x91fdf428) file#: 2 rdba: 0x00800019 (2/25) class: 19 ba: 0x91c62000set: 3 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2hash: [fcf7dd68,fcf7dd68] lru: [91fdf5b8,91fdf398]ckptq: [NULL] fileq: [NULL] objq: [f5b53d60,f5b53d60]use: [fa694970,fa694970] wait: [NULL]st: XCURRENT md: SHR tch: 0flags: gotten_in_current_modeLRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]buffer tsn: 1 rdba: 0x00800019 (2/25)scn: 0x0000.0352d07c seq: 0x01 flg: 0x00 tail: 0xd07c2601frmt: 0x02 chkval: 0x0000 type: 0x26=KTU SMU HEADER BLOCK/* 这里dump了一个tsn=1,file#=2的数据块，可以看到它的类型是KTU SMU HEADER BLOCK即某个回滚段头
*/Hex dump of block: st=0, typ_found=1
........................
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Current SQL statement for this session:
insert into smon_scn_time (thread, time_mp, time_dp, scn, scn_wrp, scn_bas,  num_mappings, tim_scn_map)
values (0, :1, :2, :3, :4, :5, :6, :7)
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?7FFFF53BC160 ? 7FFFF53BC1C0 ?7FFFF53BC100 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?7FFFF53BC160 ? 7FFFF53BC1C0 ?7FFFF53BC100 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?7FFFF53BC160 ? 7FFFF53BC1C0 ?7FFFF53BC100 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             000000003 ? 000000001 ?7FFFF53BC160 ? 7FFFF53BC1C0 ?7FFFF53BC100 ? 000000000 ?
kgesiv()+119         call     kgeriv()             0068C97C0 ? 2ABDF1D42BF0 ?000000000 ? 0F4A33EA0 ?7FFFF53BC100 ? 000000000 ?
ksesic0()+209        call     kgesiv()             0068C97C0 ? 2ABDF1D42BF0 ?000001001 ? 000000000 ?7FFFF53BCEE0 ? 000000000 ?
ktugti()+3200        call     ksesic0()            000001001 ? 0068C9940 ?000000000 ? 00000009A ?000000010 ? 101010101010101 ?
ktsftcmove()+4149    call     ktugti()             0B73F111C ? 7FFFF53BD278 ?7FFFF53BD280 ? 000000000 ?7FFFF53BD27C ? 7FFFF53BD270 ?
ktsf_gsp()+1937      call     ktsftcmove()         00000000A ? 000000000 ?000000000 ? 000000000 ?7FFFF53BD27C ? 7FFFF53BD270 ?
kdtgsp()+512         call     ktsf_gsp()           000000000 ? 7FFFF53BF460 ?000000024 ? 000000002 ?7FFFF53BF460 ? 000000000 ?
kdccak()+111         call     kdtgsp()             2ABDF1D6A2D8 ? 7FFF00000000 ?2ABDF1D68530 ? 000000002 ?7FFFF53BF460 ? 000000000 ?
kdcgcs()+5419        call     kdccak()             2ABDF1D6A2D8 ? 000000001 ?0F4A3BBA8 ? 000000000 ?2ABDF1D6A370 ? 000000000 ?
kdcgsp()+1372        call     kdcgcs()             2ABDF1D6A2D8 ? 000000001 ?0F4A3BBA8 ? 000000000 ?2ABDF1D6A370 ? 000000000 ?
kdtInsRow()+1808     call     kdcgsp()             2ABDF1D6A2D8 ? 000000001 ?0F4A3BBA8 ? 000000000 ?2ABDF1D6A370 ? 000000000 ?
insrow()+342         call     kdtInsRow()          2ABDF1D6A2D8 ? 000000001 ?0F4A3BBA8 ? 000000000 ?2ABDF1D6A370 ? 000000000 ?
insdrv()+594         call     insrow()             2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?000000000 ? 0F4A33DE0 ?2ABDF1D6A370 ? 000000000 ?
inscovexe()+404      call     insdrv()             2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?000000000 ? 2ABDF1D6D908 ?2ABDF1D6A370 ? 000000000 ?
insExecStmtExecIniE  call     inscovexe()          0F4A33DE0 ? 0F4A3C230 ?
ngine()+85                                         7FFFF53C0EF0 ? 2ABDF1D69F20 ?2ABDF1D6A370 ? 000000000 ?
insexe()+386         call     insExecStmtExecIniE  0F4A33DE0 ? 0F4A3C230 ?ngine()              2ABDF1D69F20 ? 2ABDF1D69F20 ?2ABDF1D6A370 ? 000000000 ?
opiexe()+9182        call     insexe()             0F4A333A8 ? 7FFFF53C0EF0 ?0F4A33DE0 ? 2ABDF1D69F20 ?2ABDF1D6A370 ? 2ABDF1D69F20 ?
opiall0()+1842       call     opiexe()             000000049 ? 000000003 ?7FFFF53C12F8 ? 000000001 ?
..............

针对该ORA-00600:[4097]内部错误，metalink上Note [ID 1030620.6]介绍了一种workaround的方法:

An ORA-600 [4097] can be encountered through various activities that use
rollback segments.Solution Description:
===================== The most likely cause of this is BUG 427389.  This BUG is fixed in
version 7.3.3.3.  The BUG is caused when Rollback Segments are dropped and
recreated after a shutdown abort.  It is encountered through a very specific
set of circumstances: When an instance has a rollback segment offline and the instance crashes, or
the user does a shutdown abort, the rollback segment wrap number does not get
updated.  If that segment is then dropped and recreated immediately after the
instance is restarted, the wrap number could be lower than existing wrap
numbers.  This will cause the ORA-600[4097] to occur in subsequent
transactions using Rollback. To avoid encountering this bug, rollback segments should only be dropped and
recreated after the instance has been shutdown normal and restarted.  If you
have already encountered the bug, use the following workaround:  Select segment_name, segment_id from dba_rollback_segs; Drop all Rollback Segments except for SYSTEM.  Recreate dummy (small) rollback segments with the same names in their place. Then, recreate additional rollback segments you want to keep with their permanent storage parameters.   Now drop the dummy ones. This should ensure that the segment_ids are not reused. If you ever want to add a rollback segment you have to use the workaround steps
again.  If you do not fill the dummy slots you may see the problem re-appear.

我们可以尝试drop异常恢复前已有的可能存在问题的rollback segment来规避这个问题，虽然在10g下使用AMU(automatic managed undo)但仍可以做到这一点:

SQL> alter system set "_smu_debug_mode"=4;
System altered./* 设置SMU debug模式为4以便能够手动管理回滚段 */SQL> set heading off SQL> select 'drop rollback segment "'||segment_name||'";' from dba_rollback_segs where segment_name!='SYSTEM';drop rollback segment "_SYSSMU1$";
drop rollback segment "_SYSSMU2$";
drop rollback segment "_SYSSMU3$";
drop rollback segment "_SYSSMU4$";
drop rollback segment "_SYSSMU5$";
drop rollback segment "_SYSSMU6$";
drop rollback segment "_SYSSMU7$";
drop rollback segment "_SYSSMU8$";
drop rollback segment "_SYSSMU9$";
drop rollback segment "_SYSSMU10$";
drop rollback segment "_SYSSMU11$";
drop rollback segment "_SYSSMU12$";
drop rollback segment "_SYSSMU13$";
drop rollback segment "_SYSSMU14$";
drop rollback segment "_SYSSMU15$";
drop rollback segment "_SYSSMU16$";
drop rollback segment "_SYSSMU17$";
drop rollback segment "_SYSSMU18$";
drop rollback segment "_SYSSMU19$";
drop rollback segment "_SYSSMU20$";
drop rollback segment "_SYSSMU21$";
drop rollback segment "_SYSSMU22$";
drop rollback segment "_SYSSMU23$";
drop rollback segment "_SYSSMU24$";
drop rollback segment "_SYSSMU25$";
drop rollback segment "_SYSSMU26$";
drop rollback segment "_SYSSMU27$";
drop rollback segment "_SYSSMU28$";
drop rollback segment "_SYSSMU29$";
drop rollback segment "_SYSSMU30$";30 rows selected./* 依次执行以上的drop rollback segment回滚段的命令注意当前撤销表空间上的回滚段仅能offline而无法drop掉，实际上我们需要做的也仅仅是把之前undo表空间上有问题的回滚段drop掉
*/SQL> alter rollback segment "_SYSSMU30$" offline;
Rollback segment altered.SQL> drop rollback segment "_SYSSMU30$";
drop rollback segment "_SYSSMU30$"
*
ERROR at line 1:
ORA-30025: DROP segment '_SYSSMU30$' (in undo tablespace) not allowedSQL> alter rollback segment "_SYSSMU30$" online;
Rollback segment altered.

经过以上drop问题回滚段rollback segment后，系统不再出现ORA-00600:[4097]内部错误，实例恢复正常。在系统正常后，我们有必要重置之前所设的"_smu_debug_mode"UNDO管理debug模式的隐藏参数。