如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
ORA-00600[4000]是Oracle 内核事务undo模块的一个内部报错信息，一般来说ORA-00600[4000]错误会附带一个argument ， 该arg[a]表示Undo segment number USN。
早期版本中当使用表空间传输且对传输后的表有DML时可能因为BUG而引起该错误，可以参考文档1371820.8。
到9i以上如果遇到该ORA-00600[4000]错误，则一般是 存储/OS等断电或者故障导致Oracle的undo segment的损坏， 常见于没有正常关闭实例 之后打开数据的场景中。
以下是ORA-00600[4000]的BUG 列表：
| NB | Bug | Fixed | Description |
| 16761566 | 11.2.0.4, 12.1.0.2, 12.2.0.0 | Instance fails to start with ORA-600 [4000] [usn#] | |
| 13910190 | 11.2.0.3.BP15, 11.2.0.4, 12.1.0.1 | ORA-600 [4000] from plugged in tablespace in Exadata | |
| 14741727 | 11.2.0.2.9, 11.2.0.2.BP19, 11.2.0.3.BP12, 11.2.0.3.BP13, 12.1.0.1 | Fixes for bug 12326708 and 14624146 can cause problems – backout fix | |
| + | 10425010 | 11.2.0.3, 12.1.0.1 | Stale data blocks may be returned by Exadata FlashCache |
| * | 9145541 | 11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1 | OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g |
| 12353983 | ORA-600 [4000] with XA in RAC | ||
| 7687856 | 11.2.0.1 | ORA-600 [4000] from DML on transported ASSM tablespace | |
| 2917441 | 11.1.0.6 | OERI [4000] during startup | |
| 3115733 | 9.2.0.5, 10.1.0.2 | OERI[4000] / index corruption can occur during index coalesce | |
| 2959556 | 9.2.0.5, 10.1.0.2 | STARTUP after an ORA-701 fails with OERI[4000] | |
| 1371820 | 8.1.7.4, 9.0.1.4, 9.2.0.1 | OERI:4506 / OERI:4000 possible against transported tablespace | |
| + | 434596 | 7.3.4.2, 8.0.3.0 | ORA-600[4000] from altering storage of BOOTSTRAP$ |
常见修复ORA-00600[4000]的手段包括使用ADJUST_SCN事件或者_MINIMUM_GIGA_SCN调整SCN，或者使用其他隐藏参数，或者对undo segment/ITL 使用BBED手动修改等。
如果自己搞不定可以找ASKMACLEAN专业数据库修复团队成员帮您恢复!
Bug 16761566 – INSTANCE FAILED TO START WITH ORA-600 [4000] [USN#]
注意对于 SYSTEM表空间执行exec dbms_space_admin.tablespace_fix_segment_extblks(‘SYSTEM’);的话可能意外导致
ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [4000], [170], [], [], [], [], [], [], [], [], [], []
所以建议永远也不要对 SYSTEM表空间执行，DBMS_SPACE_ADMIN.TABLESPACE_FIX_SEGMENT_EXTBLKS 。
为了修复这种损坏，一般需要用到PITR point in time recovery ; 如果根本没备份 ，那么实际只好手动修改bootstrap$对象的segment header了。
Database fails to start because of ora-600[4000].Alert.log will show:Errors in file /oracle/admin/sdwh/udump/sdwh_ora_13186.trc:ORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00600: internal error code, arguments: [4000],
, [], [], [], [], [], []Tue Sep 9 14:48:04 2008Error 704 happened during db open, shutting down databasesdwh_ora_13186.trc shows:*** 2008-09-09 15:33:26.194ksedmp: internal or fatal errorORA-00600: internal error code, arguments: [4000], 
, [], [], [], [], [], []Current SQL statement for this session:select ctime, mtime, stime from obj$ where obj# = :1….row cache parent object: address=0xc9efb27c cid=3(dc_rollback_segments)hash=35e74caf typ=5 transaction=(nil) flags=00000001own=0xc9efb2f0[0xc7c83ba0,0xc7c83ba0] wat=0xc9efb2f8[0xc9efb2f8,0xc9efb2f8] mode=Sstatus=EMPTY/-/-/-/-/-/-/-/-data=00000001 ….BH (0x0x6ffff4ac) file#: 1 rdba: 0x0040007a (1/122) class 1 ba: 0x0x6ff8a000set: 17 dbwrid: 0 obj: 18 objn: 18hash: [74ffdc70,c85d94cc] lru: [6ffffad4,c771aabc]ckptq: [NULL] fileq: [NULL]use: [c84043f0,c84043f0] wait: [NULL]st: XCURRENT md: SHR rsop: 0x(nil) tch: 0LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]Using State Objects—————————————-SO: 0xc84043d0, type: 24, owner: 0xc722382c, flag: INIT/-/-/0x00(buffer) (CR) PR: 0x0xc71d1440 FLG: 0x500400lock rls: 0x(nil), class bit: 0x(nil)kcbbfbp: [BH: 0x0x6ffff4ac, LINK: 0x0xc84043f0]where: kdswh02: kdsgrp, why: 0buffer tsn: 0 rdba: 0x0040007a (1/122)scn: 0x0000.15ad85b0 seq: 0x01 flg: 0x06 tail: 0x85b00601frmt: 0x02 chkval: 0xabfc type: 0x06=trans dataBlock header dump: 0x0040007aObject id on Block? Yseg/obj: 0x12 csc: 0x00.15ad85ad itc: 1 flg: – typ: 1 – DATAfsl: 0 fnx: 0x0 ver: 0x01Itl Xid Uba Flag Lck Scn/Fsc0x01 0x0001.027.000056dc 0x0080d065.16f2.14 –U- 1 fsc 0x0000.15ad85b0Trace file shows _SYSSMU1$ has a TX against obj$, and the scn ofthe block touched by this TX is scn:0x0000.15ad85b0 –> 363693488 decimal.The ora-600[4000] could be raised at startup if the above scn is ahead of the database SCN.Instructions for the ReaderA Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist introubleshooting.Troubleshooting Details1) Find database SCNSQL> startup mountSQL> select checkpoint_change# from v$database;2) SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual;3) set parameter _minimum_giga_scn= in the init.ora file.Using the above trace file example, we found:SQL> select checkpoint_change# from v$database;355532971As suspected the database scn = 355532971 is lower than TX scn=363693488.SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual;Enter value for decimal_scn_expected: 363693488old 1: select ceil(&decimal_scn_expected/1024/1024/1024) from dualnew 1: select ceil(363693488/1024/1024/1024) from dualCEIL(363693488/1024/1024/1024)——————————11) set parameter _minimum_giga_scn=1 in the init.ora file.2) open the databasestartup mountrecover databasealter database open;4) Startup databaseSQL> startup mountSQL> recover databaseSQL> alter database open;5) If database opens:- remove parameter _minimum_giga_scn from init.ora and bounce databaseSQL> shutdown immediateSQL> startup6) Investigate what could cause the ora-600[4000] , could be because customer forced to open databaseusing _allow_resetlogs_corruption, and if this is the case we strongly suggest to recreate the databasefrom scratch taking a full export.