联系：手机/微信(+86 17813235971) QQ(107644445)
标题：ORA-600 ktbair2: illegal inheritance恢复
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
接到客户一个恢复case咨询,数据库open过程报ORA-00600: 内部错误代码, 参数: [ktbair2: illegal inheritance]错误
查看alert日志
2025-12-21T10:38:49.346922+08:00 alter database open 2025-12-21T10:38:50.286621+08:00 Ping without log force is disabled: instance mounted in exclusive mode. 2025-12-21T10:38:50.300632+08:00 Beginning crash recovery of 1 threads 2025-12-21T10:38:50.378690+08:00 parallel recovery started with 32 processes Thread 1: Recovery starting at checkpoint rba (logseq 47910 block 201391), scn 0 2025-12-21T10:38:50.446742+08:00 Started redo scan 2025-12-21T10:38:50.597853+08:00 Completed redo scan read 57808 KB redo, 409 data blocks need recovery 2025-12-21T10:38:50.827024+08:00 Started redo application at Thread 1: logseq 47910, block 201391, offset 0 2025-12-21T10:38:50.845043+08:00 Recovery of Online Redo Log: Thread 1 Group 3 Seq 47910 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\REDO03.LOG 2025-12-21T10:38:50.929100+08:00 Completed redo application of 3.15MB 2025-12-21T10:38:50.975134+08:00 Errors in file F:\APP\diag\rdbms\srmdev\srmdev\trace\srmdev_p00e_11192.trc (incident=1382836): ORA-00600: 内部错误代码, 参数: [ktbair2: illegal inheritance], [], [], [], [], [], [], [], [], [], [], [] Incident details in: F:\APP\diag\rdbms\srmdev\srmdev\incident\incdir_1382836\srmdev_p00e_11192_i1382836.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2025-12-21T10:38:52.033922+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** ………… 2025-12-21T10:39:02.224702+08:00 Errors in file F:\APP\diag\rdbms\srmdev\srmdev\trace\srmdev_ora_9960.trc: ORA-01578: ORACLE 数据块损坏 (文件号 7, 块号 611) ORA-01110: 数据文件 7: 'F:\APP\ORADATA\SRMDEV\USERS01.DBF' ORA-10564: tablespace USERS ORA-01110: 数据文件 7: 'F:\APP\ORADATA\SRMDEV\USERS01.DBF' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 74736 ORA-00600: 内部错误代码, 参数: [ktbair2: illegal inheritance], [], [], [], [], [], [], [], [], [], [], [] ORA-1578 signalled during: alter database open...
这个错误以前有过类似处理,主要是由于redo无法正确应用,数据库在open过程无法正常完成实例恢复所以出现该问题.以前处理过类似案例:
Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
这次的故障相对简单一些,通过一些简单尝试之后数据库正常应用成功
2025-12-21T21:43:00.689653+08:00 ALTER DATABASE RECOVER datafile 1 2025-12-21T21:43:00.691654+08:00 Media Recovery Start 2025-12-21T21:43:00.693656+08:00 Serial Media Recovery started 2025-12-21T21:43:00.721676+08:00 Recovery of Online Redo Log: Thread 1 Group 3 Seq 47910 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\REDO03.LOG Completed: ALTER DATABASE RECOVER datafile 1 2025-12-21T21:43:14.109099+08:00 ALTER DATABASE RECOVER datafile 3 2025-12-21T21:43:14.111100+08:00 Media Recovery Start 2025-12-21T21:43:14.113102+08:00 Serial Media Recovery started 2025-12-21T21:43:14.139121+08:00 Recovery of Online Redo Log: Thread 1 Group 3 Seq 47910 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\REDO03.LOG Completed: ALTER DATABASE RECOVER datafile 3 2025-12-21T21:43:21.361498+08:00 ALTER DATABASE RECOVER datafile 4 2025-12-21T21:43:21.363499+08:00 Media Recovery Start 2025-12-21T21:43:21.365500+08:00 Serial Media Recovery started 2025-12-21T21:43:21.397524+08:00 Media Recovery failed with error 264 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 4 ... 2025-12-21T21:43:31.909350+08:00 ALTER DATABASE RECOVER datafile 7 2025-12-21T21:43:31.911351+08:00 Media Recovery Start 2025-12-21T21:43:31.913353+08:00 Serial Media Recovery started 2025-12-21T21:43:31.940373+08:00 Recovery of Online Redo Log: Thread 1 Group 3 Seq 47910 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\REDO03.LOG Completed: ALTER DATABASE RECOVER datafile 7
然后比较幸运直接open数据库成功,但是报ORA-600 4194错误
2025-12-21T21:45:34.003260+08:00 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set stopping change tracking 2025-12-21T21:45:34.262453+08:00 Undo initialization recovery: err:0 start: 45858156 end: 45858296 diff: 140 ms (0.1 seconds) [13724] Successfully onlined Undo Tablespace 2. Undo initialization online undo segments: err:0 start: 45858296 end: 45858359 diff: 63 ms (0.1 seconds) Undo initialization finished serial:0 start:45858156 end:45858359 diff:203 ms (0.2 seconds) Verifying minimum file header compatibility for tablespace encryption.. Verifying file header compatibility for tablespace encryption completed for pdb 0 Database Characterset is AL32UTF8 2025-12-21T21:45:34.584694+08:00 Errors in file F:\APP\diag\rdbms\srmdev\srmdev\trace\srmdev_smon_13616.trc (incident=1510624): ORA-00600: 内部错误代码, 参数: [4194], [58], [49], [], [], [], [], [], [], [], [], [] Incident details in:F:\APP\diag\rdbms\srmdev\srmdev\incident\incdir_1510624\srmdev_smon_13616_i1510624.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2025-12-21T21:45:34.598703+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 2025-12-21T21:45:35.634474+08:00 Autotune of undo retention is turned off. 2025-12-21T21:45:35.636476+08:00 Resource Manager disabled during database migration: plan '''' not set Resource Manager disabled during database migration 2025-12-21T21:45:36.009753+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** Doing block recovery for file 4 block 27127 Resuming block recovery (PMON) for file 4 block 27127 Block recovery from logseq 47911, block 78 to scn 0x0000000000000000 2025-12-21T21:45:36.026766+08:00 Recovery of Online Redo Log: Thread 1 Group 4 Seq 47911 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\RED004.LOG Block recovery completed at rba 0.0.0, scn 0x00000006a378f1bc Doing block recovery for file 4 block 176 Resuming block recovery (PMON) for file 4 block 176 Block recovery from logseq 47911, block 78 to scn 0x00000006a378f23d 2025-12-21T21:45:36.045781+08:00 Recovery of Online Redo Log: Thread 1 Group 4 Seq 47911 Reading mem 0 Mem# 0: F:\APP\ORADATA\SRMDEV\RED004.LOG Block recovery completed at rba 47911.78.16, scn 0x00000006a378f23e Non-fatal internal error happened while SMON was doing shrinking of rollback segments. SMON encountered 1 out of maximum 100 non-fatal internal errors. replication_dependency_tracking turned off (no async multimaster replication found) 2025-12-21T21:45:36.493113+08:00 AQ Processes can not start in restrict mode Starting background process CJQ0 2025-12-21T21:45:36.545152+08:00 CJQ0 started with pid=73, OS id=14120 2025-12-21T21:45:37.546898+08:00 Completed: alter database open
这个处理起来比较简单,对于异常的undo进行处理之后,数据库正常导出dmp,完成本次恢复任务
