某用户11.1.0.6的系统在系统断电重启后遭遇了ORA-600 [4194]错误：
Starting background process QMNC Wed Dec 10 21:26:24 2014 QMNC started with pid=21, OS id=2932 Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc (incident=33600227): ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600227\erp_smon_3612_i33600227.trc Doing block recovery for file 3 block 4378 Block recovery from logseq 1, block 127 to scn 1309041534 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG Block recovery stopped at EOT rba 1.129.16 Block recovery completed at rba 1.129.16, scn 0.1309041534 Doing block recovery for file 3 block 121 Block recovery from logseq 1, block 127 to scn 1309041531 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG Block recovery completed at rba 1.128.16, scn 0.1309041533 Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc: ORA-01595: 释放区 (2) 回退段 (8) 时出错 ORA-00607: 当更改数据块时出现内部错误 ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], [] LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Wed Dec 10 21:26:26 2014 Trace dumping is performing id=[cdmp_20141210212626] Wed Dec 10 21:26:31 2014 Sweep Incident[33600227]: completed Wed Dec 10 21:26:31 2014 Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_m004_4524.trc (incident=33600347): ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600347\erp_m004_4524_i33600347.trc Trace dumping is performing id=[cdmp_20141210212632] Doing block recovery for file 3 block 4378 Block recovery from logseq 1, block 127 to scn 1309041534 ump of buffer cache at level 4 for tsn=2, rdba=12587290 BH (0x000000016BFB7308) file#: 3 rdba: 0x00c0111a (3/4378) class: 32 ba: 0x000000016B7EA000 set: 11 bsz: 8192 bsi: 0 sflg: 2 pwc: 51 lid: 0x00000000,0x00000000 dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3 hash: [0x00000001E2F7DCC0,0x00000001E2F7DCC0] lru: [0x000000016BFB74C8,0x000000016BFB7268] obj-flags: object_ckpt_list ckptq: [0x000000016BF8F7F8,0x000000016BFB7478] fileq: [0x00000001E3BDB698,0x000000016BFB7488] objq: [0x000000016BFEAFC8,0x000000016BF821D8] use: [0x00000001D8653448,0x00000001D8653448] wait: [NULL] st: XCURRENT md: EXCL tch: 0 flags: buffer_dirty mod_started gotten_in_current_mode change state: ACTIVE change count: 1 LRBA: [0x14.7d.0] LSCN: [0x0.4e0c7c32] HSCN: [0x0.4e0c7c32] HSUB: [65535] cr pin refcnt: 0 sh pin refcnt: 0 buffer tsn: 2 rdba: 0x00c0111a (3/4378) scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202 frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK *** ktuc_diag_dmp: dump of redo for rdba 0x00c0111a Cleaning up copy latch 0 Copy latch cleanup completed DUMP REDO Opcodes *.* DBAs (file#, block#): (3, 4378) . SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff **NOTE: Only Dumping Redo less then 12 hours** Times: 12/10/2014 21:23:27 thru eternity *** 2014-12-11 09:23:27.382 SCN Start Scan Point: scn: 0x0000.4e0bd8c2 (1309399234) INCARNATION: START: scn: 0x0000.4e0662ee (1309041390) Timestamp: 12/10/2014 21:26:17 END: scn: 0xffff.ffffffff descrip:"Thread 0001, Seq# 0000000018, SCN 0x00004e0bd8c2-0x00004e0c295e" REDO RECORD - Thread:1 RBA: 0x000012.00000002.0010 LEN: 0x0070 VLD: 0x05 SCN: 0x0000.4e0bd8c4 SUBSCN: 1 12/11/2014 09:19:10 CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3 descrip:"Thread 0001, Seq# 0000000019, SCN 0x00004e0c295e-0x00004e0c79f5" REDO RECORD - Thread:1 RBA: 0x000013.00000002.0010 LEN: 0x0070 VLD: 0x05 SCN: 0x0000.4e0c2960 SUBSCN: 1 12/11/2014 09:20:14 CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3 descrip:"Thread 0001, Seq# 0000000020, SCN 0x00004e0c79f5-0xffffffffffff" REDO RECORD - Thread:1 RBA: 0x000014.00000002.0010 LEN: 0x0070 VLD: 0x05 SCN: 0x0000.4e0c79f7 SUBSCN: 1 12/11/2014 09:23:13 CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3 END OF DUMP REDO Incident 35120409 created, dump file: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_35120409\erp_ora_548_i35120409.trc ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], [] Error 607 in redo application callback Dump of change vector: TYP:0 CLS:32 AFN:3 DBA:0x00c0111a OBJ:4294967295 SCN:0x0000.4e0662ff SEQ: 2 OP:5.1 ktudb redo: siz: 208 spc: 1094 flg: 0x0012 seq: 0x91a4 rec: 0x3b xid: 0x0008.01d.001511ce ktubl redo: slt: 29 rci: 0 opc: 11.1 objn: 74 objd: 74 tsn: 0 Undo type: Regular undo Begin trans Last buffer split: No Temp Object: No Tablespace Undo: No 0x00000000 prev ctl uba: 0x00c0111a.91a4.39 prev ctl max cmt scn: 0x0000.4e065bc8 prev tx cmt scn: 0x0000.4e065be6 txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12587289 prev bcl: 0 BuExt idx: 0 flg2: 0 KDO undo record: KTB Redo op: 0x04 ver: 0x01 compat bit: 4 (post-11) padding: 0 op: L itl: xid: 0x000d.012.000346f7 uba: 0x00c01d8e.1899.2a flg: C--- lkc: 0 scn: 0x0000.4e0c7c3e KDO Op code: URP row dependencies Disabled xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x00400222 hdba: 0x00400221 itli: 1 ispac: 0 maxfr: 4863 tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0 ncol: 10 nnew: 9 size: 0 Vector content: col 1: [ 2] c1 02 col 2: [ 2] c1 02 col 3: [ 2] c5 15 col 4: [ 2] c1 02 col 5: [ 1] 80 col 6: [ 2] c3 02 col 7: [ 5] c4 06 4a 13 0b col 8: [32] 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d col 9: [ 1] 80 Block after image is corrupt: buffer rdba: 0x00c0111a scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202 frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK Hex dump of block: st=0, typ_found=1 Dump of memory from 0x000000016B7EA000 to 0x000000016B7EC000 16B7EA000 0000A202 00C0111A 4E0662FF 04020000 [.........b.N....]
该ORA-00600: 内部错误代码, 参数: [4194]错误我们之前有多次提过，
【Oracle数据恢复】通过BBED修复ORA-600[4193]和ORA-600[4194]的例子
ORA-600[4194]内部错误一般由重做记录与回滚记录不匹配引发。Oracle在验证Undo record number时，会对比redo change 和回滚段中的undo record number，若发现2者存在差异则报该4194错误。其错误argument[a][b]，a代表回滚块中的最大undo record number，b代表重做日志中记录的undo record number。这个错误可能由回滚段或者redo log日志文件讹误引起。
ORA-00600[4194]错误的根本原因是 redo记录与回滚段(rollback/undo)记录之间的不一致。当ORACLE在验证undo记录时相对应的变化需要应用到undo数据块的最大undo记录上，此时若检验出错则会报ORA-00600[4194]
ORA-600[4194]的2个的含义：
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block
以上可以通过trace定位到可能存在触发该UNDO问题的数据块是rdba: 0x00c0111a (3/4378)， 该问题一般可以通过设置EVENT、隐藏参数或BBED来修复。
Comment