一套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模式的隱藏參數。

總結

以上是生活随笔為你收集整理的Oracle内部错误:ORA-00600:[4097]一例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。