在正常 open 的过程中，报错如下错误：

SQL> alter database open;

alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [],
[], [], []
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 4294967296 bytes
Fixed Size 2089576 bytes
Variable Size 2751466904 bytes
Database Buffers 1526726656 bytes
Redo Buffers 14684160 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [],[], [], []

对于该错误，网上的解决方法也很多，可惜都不管用。这种情况之下，往往都是需要强制打开
数据库的，首先需要做一个不完全恢复，如下：
SQL> recover database
ORA-00279: change 236912204 generated at 09/29/2015 12:49:13 needed for thread 1
ORA-00289: suggestion : /xxxx/1_5112_877094801.dbf
ORA-00280: change 236912204 for thread 1 is in sequence #5112
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log '/xxxx/1_5112_877094801.dbf'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3

在进行相关操作之后，我备份了一下当前的控制文件信息，便于后面如果有问题，方便处理。
强制 open 的过程中，发现报如下错误：
Sat Oct 3 11:49:31 2015
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Sat Oct 3 11:49:33 2015
Errors in file /oracle/oracle/admin/cwdb/udump/cwdb1_ora_6029586.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [1], [18446744072394632417], [1],
[18446744072392296306], [], [], []
Sat Oct 3 11:49:34 2015
Errors in file /oracle/oracle/admin/xxxx/udump/xxxx1_ora_6029586.trc:
ORA-00600: internal error code, arguments: [kclchkblk_4], [1], [18446744072394632417], [1],
[18446744072392296306], [], [], []
Sat Oct 3 11:49:34 2015
Error 600 happened during db open, shutting down database
USER: terminating instance due to error 600
Instance terminated by USER, pid = 6029586
这个错误已经处理过多次了。同样，百度一下，会发现很多人都写过相关的文章，包括 Oracle
mos 的文章解释也是说这是临时块的 scn 过大导致，通过 drop tempfile 即可绕过该问题。实际
上，这种情况之下，根本不会起作用。但是不管如何，这个问题很明显都是跟 block 的 scn 有
关系。既然是跟 scn 有关系，那么处理就不难了，通过推进 scn 即可。
通过推进 scn 之后，再次 open resetlogs 成功打开数据库，可惜的是 alert log 报了一堆错误，如
下所示：
Sat Oct 3 13:10:34 2015
Errors in file /oracle/oracle/admin/xxxx/bdump/xxxx1_smon_10420246.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 40
Sat Oct 3 13:10:35 2015
ORACLE Instance xxxx1 (pid = 25) - Error 600 encountered while recovering transaction (23, 85).
Sat Oct 3 13:10:35 2015
Errors in file /oracle/oracle/admin/xxxx/bdump/xxxx1_smon_10420246.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Sat Oct 3 13:10:35 2015
Trace dumping is performing id=[cdmp_20151003131035]
Sat Oct 3 13:10:35 2015
replication_dependency_tracking turned off (no async multimaster replication found)
Sat Oct 3 13:10:36 2015
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Sat Oct 3 13:10:36 2015
Errors in file /oracle/oracle/admin/xxxx/bdump/xxxx1_smon_10420246.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Sat Oct 3 13:10:37 2015
Starting background process QMNC
Sat Oct 3 13:10:37 2015
ORACLE Instance xxxx1 (pid = 25) - Error 600 encountered while recovering transaction (23, 85).
Sat Oct 3 13:10:37 2015
Errors in file /oracle/oracle/admin/xxxx/bdump/xxxx1_smon_10420246.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
QMNC started with pid=53, OS id=7536816
Sat Oct 3 13:10:41 2015
LOGSTDBY: Validating controlfile with logical metadata
Sat Oct 3 13:10:41 2015
LOGSTDBY: Validation complete
Sat Oct 3 13:10:46 2015
Errors in file /oracle/oracle/admin/xxxx/bdump/xxxx1_mmon_9110004.trc:
ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []
Sat Oct 3 13:10:48 2015
Errors in file /oracle/oracle/admin/xxxx/udump/xxxx1_ora_6619434.trc:
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []
Completed: alter database open resetlogs

这部分错误处理其实都不难。对于第一个 ora-00600 [4137] 错误，很明显这是跟 undo 有关系的，

其中(23,85)中的 23 表现第 23 号回滚段；通过屏蔽第 23 号回滚段可以很容易解决该错误，当然，
这会儿导致事务的不一致性，这是没办法的，已经 undo 异常，Oracle 已经没有办法进行正常
的事务恢复了。
其次，对于第 2 个 ora-00600 [qertbFetchByRowID] 错误，处理也很简单，其大致意思是通过
rowid 访问获取数据有异常，很明显这是跟 index 有关系，通过重建 index 可以解决该问题，其
次最后一个[kdsgrp1] 错误就更常见了，通常也是 Index 的问题，重建即可。

看上去一切的恢复过程都很简单，很顺利，然而这里真正的难题，真正的问题才开始。
也就是最后一个看似很简单的错误 ora-00600 [kdsgrp1]错误，对我们产生了极大的困难。首先
我们来看下产生该错误时涉及到那些对象：
Validate domain 0
Validated domain 0, flags = 0x0
kwqmnich: current time:: 13: 31: 34
kwqmnich: instance no 0 check_only flag 1
kwqmnich: initialized job cache structure
row 0041edda.2e continuation at
file# 1 block# 126426 slot 47 not found
**************************************************
KDSTABN_GET: 0 ..... ntab: 1
curSlot: 47 ..... nrows: 175
**************************************************
*** 2015-10-03 13:31:40.864
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []
Current SQL statement for this session:
SELECT OWNER,NAME,TYPE,COUNT(*) FROM DBA_SOURCE WHERE
SUBSTR(OWNER,1,4)='FMIS' GROUP BY OWNER,NAME,TYPE HAVING COUNT(*)>1000
----- PL/SQL Call Stack -----
Object id on Block? Y
seg/obj: 0x12 csc: 0x01.b1957474 itc: 3 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.00e.0003968d 0x0c07f50f.1ea7.5d --U- 1 fsc 0x0053.b1957475
0x02 0x0017.005.0006755c 0x0c0774de.1be3.38 C--- 0 scn 0x0001.b1957451
0x03 0x0002.042.00010d39 0x0080b268.0cf1.22 C--- 0 scn 0x0001.b1957429
data_block_dump,data header at 0x110f46074
===============
tsiz: 0x3f88
hsiz: 0x170
pbl: 0x110f46074
bdba: 0x0041edda
76543210
flag=--------
ntab=1
nrow=175
frre=0
fsbo=0x170
fseo=0x783
avsp=0x3cbe
tosp=0x3d13
0xe:pti[0] nrow=175 offs=0
0x12:pri[0] sfll=1
0x14:pri[1] sfll=2
我们可以发现，除开其他的非核心对象之后，这里还涉及到一个 obj#=18，也就是 obj$ 这个核
心的数据字典表。而该数据字典表上的几个 Index，i_obj1，i_obj2，i_obj3 都是 object_id 小于
57 的核心对象，这部分对象是属于 bootstrap$ 的核心数据字典对象。即是 Index 也无法通过 re
build，38003 event 或在 upgrade 模式下进行重建。
当然，这里也不是说完全无法去重建上述数据字典表，后面有一篇文章会讲解如何去重建。
在分析过程中，我发现其中的前面 2 个 Index 都有问题，如下：
SQL> analyze table obj$ validate structure;
Table analyzed.
SQL> select index_name from dba_indexes where table_name='OBJ$';
INDEX_NAME
------------------------------
I_OBJ1
I_OBJ2
I_OBJ3
SQL> analyze index I_OBJ1 validate structure;
analyze index I_OBJ1 validate structure
*
ERROR at line 1:
ORA-08100: index is not valid - see trace file for diagnostics
SQL> analyze index I_OBJ2 validate structure;
analyze index I_OBJ2 validate structure
*
ERROR at line 1:
ORA-08100: index is not valid - see trace file for diagnostics
SQL> analyze index I_OBJ3 validate structure;
Index analyzed.

不过，这里我们也要注意的时，虽然前面 2 个 index 都有问题，然而上述错误产生时涉及到的

in dex 并不是 2 个都用到了，其实只是用到了第一个 index 就报错 ora-00600 错误了。由于客户
想通过 expdp schema 的方式去导出数据，然而发现执行时报错 ora-00600 [kdsgrp1],包括 exp 执
行时也报该错误，不过 exp tables 的方式不会报错；由于对象太多，将近 50 万个对象（包括表，
index 以及其他）。很明显，只能通过用户级别的导出。那么也就在意味着我们必须修复这个
错误才能通过 dump 相关的 block，我们发现错误是很奇怪的，如下：
*** SESSION ID:(1052.1243) 2015-10-03 17:56:59.784
Block Checking: DBA = 4684328, Block Type = KTB-managed data block
*** previous block dba dba: 477a2adoes not match my previous block dba dba: 477a26
**** row 0: key out of order
---- end index block validation
---- for block 4684328 = 0x00477a28
Block header dump: 0x00477a28
Object id on Block? Y
seg/obj: 0x24 csc: 0x02.80026908 itc: 19 flg: O typ: 2 - INDEX
fsl: 0 fnx: 0x477a1c ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0015.01f.00020a0a 0x00867c38.0862.04 C--- 0 scn 0x0001.83f32656
0x02 0x002e.044.00002415 0x0082989a.0477.52 C--- 0 scn 0x0001.74d90109
0x03 0x002c.00a.000012c5 0x0b804b78.012b.70 C--- 0 scn 0x0001.74d9011c
0x04 0x0002.001.00003a72 0x00861aab.024b.0a C--- 0 scn 0x0001.74fa8cf1
0x05 0x002f.02e.000065eb 0x0b816866.0217.5b C--- 0 scn 0x0001.74fb0205
0x06 0x0026.011.00002000 0x0b814f02.016d.14 C--- 0 scn 0x0001.74fc3dbf
0x07 0x0006.011.00003b1c 0x0084c65b.01f9.10 C--- 0 scn 0x0001.74fde478
0x08 0x0029.05f.00003258 0x0084faa6.017c.2f C--- 0 scn 0x0001.74fdedad
0x09 0x001b.023.00003fe6 0x008a8718.025b.3b C--- 0 scn 0x0001.74fdfedc
0x0a 0x001b.006.00004057 0x0b804f24.025c.33 C--- 0 scn 0x0001.751a25ed
0x0b 0x001b.02a.00004039 0x0b804f24.025c.49 C--- 0 scn 0x0001.751a2609
0x0c 0x001b.024.0000404f 0x0b804f24.025c.63 C--- 0 scn 0x0001.751a2627
0x0d 0x000a.018.00021b0b 0x0b821c8b.04cc.45 C--- 0 scn 0x0001.751a263f
0x0e 0x000a.055.00021b0a 0x0b821c8b.04cc.5e C--- 0 scn 0x0001.751a265c
0x0f 0x000a.031.00021aec 0x0b821c8c.04cc.09 C--- 0 scn 0x0001.751a2678
0x10 0x0022.05e.00001dbd 0x008a88df.01e0.2e C--- 0 scn 0x0001.74d8ff09
0x11 0x0025.010.00001ead 0x00860446.01ac.20 C--- 0 scn 0x0001.74d8ff7d
0x12 0x002b.043.00001228 0x0084dc65.0164.11 C--- 0 scn 0x0001.74d8ffe2
0x13 0x001f.015.00001de8 0x0b81a76a.0183.4e C--- 0 scn 0x0001.74d90071
Leaf block dump
===============
header address 504403185228956148=0x70000064725c1f4
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 1
kdxcosdc 2
kdxconro 0
kdxcofbo 36=0x24
kdxcofeo 15816=0x3dc8
kdxcoavs 15780
kdxlespl 0
kdxlende 0
kdxlenxt 4684330=0x477a2a
kdxleprv 4684326=0x477a26
kdxledsz 6
kdxlebksz 15816
*** dummy key ***
row#0[9549] flag: ---D--, lock: 0, len=14, data:(6): 00 44 03 10 00 7c
col 0; len 5; (5): c4 04 24 25 2f
----- end of leaf block dump -----
dumping parent of corrupted subtree, row # = 1202
dumping parent of corrupted subtree, row # = 3

对于上述这个 index 的错误，我是第一次遇见，跟老熊讨论了一下，他认为可能是 index split

情况之下出现的。在远程时，我也用过 bbed 对前后将近 10 个 index block 进行了分析，通过比
较 index 的链表，发现确实不匹配。
对于这种情况之下，想通过 bbed 去修复 index，难度可想而知，因此果断放弃这种方式。最后
无奈之下，只能通过处理数据字典表的方式来处理掉 i_obj1，i_obj2 这 2 个 index。最后再让客
户进行 exp 用户级别的导出，只不过这个导出的时间比较漫长了。

RROR: ORA-600 [kdsgrp1]

VERSIONS: versions 10.1 and above

DESCRIPTION:
This error was introduced in 10g with the fix to Bug 2442351, it provides for an extra health check
on a block, we detected a null row header, see Note:2442351.9 for more information.
Error may be caused by:
Case 1. A row referenced in an index that does not exist in the table.
Case 2. An non-existent rowid pointed to by a chained row.

Trace Examples:

Case 1. Mismatch between table and index:

====================================================
Trace file has:
row 02433566.13 continuation at
file# 9 block# 210278 slot 20 not found

The file=9 block=210278 is rdba=0x02433566 which was taken from an index:

row#3[7549] flag: ------, lock: 0, len=85, data:(6): 02 43 35 66 00 14

But the slot 20 does not exist in the table block:

tab 0, row 1, @0x1e62
tl: 2 fb: --HDFL-- lb: 0x3
tab 0, row 12, @0x191a
tl: 2 fb: --HDFL-- lb: 0x1
tab 0, row 17, @0x1675
tl: 2 fb: --HDFL-- lb: 0x2
tab 0, row 21, @0x1459
tl: 2 fb: --HDFL-- lb: 0x4

ORA-1499 may be produced by analyze:

analyze table <table name> validate structure cascade;

Case 2. A row points to another rowid which does not exist (Chained row does not exist).
========================================================================
Trace file has:

row 1186b11a.ffffffff continuation at

file# 70 block# 441621 slot 1 not found

It means that row with rdba 0x1186b11a continues in file# 70 block# 441621 slot 1.
But the information in file# 70 block# 441621 slot 1 does not exist. It is:
tab 0, row 16, @0xd7f ---> This is the slot with the problem.
tl: 29 fb: -------- lb: 0x0 cc: 11
nrid: 0x1186bd15.1 ---> It points to rdba=0x1186bd15 slot 1
(file# 70 block# 441621 slot 1) but that row does not exist in that block.

For this case ANALYZE TABLE .. VALIDATE STRUCTURE is not detecting this logical
corruption
Referece Bug 6858313

Run an export (exp) or Full Table Scan to identify if there is a permanent invalid chained row.

Workaround for Case 2:

The row producing the ORA-600 [kdsgrp1] can be skipped by setting the Event 10231
 Note that a testcase has concluded that event 10231 does not skip rows in an Index Organized Table
(IOT)
when there is an invalid nrid as explained in Case 2. It only works for regular tables.

Event 43810 skip corrupt block in IOT?s (10.2.0.4)

nor parameter _index_scan_check_skip_corrupt (11g) work for this case 2 on IOTs either.

FUNCTIONALITY:
Kernel Data layer Seek/Scan

IMPACT:

PROCESS FAILURE
POSSIBLE PHYSICAL CORRUPTION

ALTER INDEX SMON_SCN_TIME_SCN_IDX REBUILD ONLINE;

ANALYZE TABLE smon_scn_time VALIDATE STRUCTURE CASCADE ONLINE;

Select index_name,index_type,owner from dba_indexes where table_name='SMON_SCN_TIME';

Select dbms_metadata.get_ddl('INDEX','SMON_SCN_TIME_TIM_IDX','SYS') FROM DUAL ;
CREATE UNIQUE INDEX "SYS"."SMON_SCN_TIME_TIM_IDX" ON
"SYS"."SMON_SCN_TIME" ("T
IME_MP")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM"

Select dbms_metadata.get_ddl('INDEX','SMON_SCN_TIME_SCN_IDX','SYS') FROM DUAL ;

CREATE UNIQUE INDEX "SYS"."SMON_SCN_TIME_SCN_IDX" ON

"SYS"."SMON_SCN_TIME" ("SCN")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "SYSTEM";

Drop index sys.SMON_SCN_TIME_TIM_IDX ;

Drop index sys.SMON_SCN_TIME_SCN_IDX ;

@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql
@?/rdbms/admin/utirp.sql
@?/rdbms/admin/utlrp.sql
@?/rdbms/admin/catupgrd.sql

A checklist for handling ORA-600 [kdsgrp1].

First: what is going on? Checking the table on inconsistency:
SQL> analyze table DWH_TEST.DWH validate structure online;
ERROR at line 1:
ORA-01498: block check failure – see trace file. I know now that in this trace-file there is one line
very intriging:

nrow=624 ==> 624 rows in corrupted blocks…. bloody hell !

Using dbms_repair for repairing this. Checklist (sources are on the bottom):

1). Connected as SYS: Creating repair table ‘REPAIR_TABLE’ and view ‘DBA_REPAIR_TABLE’:
BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => ‘REPAIR_TABLE’,
TABLE_TYPE => dbms_repair.repair_table,
ACTION => dbms_repair.create_action,
TABLESPACE => ‘USERS’);
END;
/

2). Create Orphan keys table ‘ORPHAN_KEY_TABLE’ and view ‘DBA_ORPHAN_KEY_TABLE’.

BEGIN
DBMS_REPAIR.ADMIN_TABLES (
TABLE_NAME => ‘ORPHAN_KEY_TABLE’,
TABLE_TYPE => dbms_repair.orphan_table,
ACTION => dbms_repair.create_action,
TABLESPACE => ‘USERS’);
END;
/

3). Checking the object:

SET SERVEROUTPUT ON
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => ‘DWH_TEST’,
OBJECT_NAME => ‘DWH’,
REPAIR_TABLE_NAME => ‘REPAIR_TABLE’,
CORRUPT_COUNT => num_corrupt);
DBMS_OUTPUT.PUT_LINE(‘number corrupt: ‘ || TO_CHAR (num_corrupt));
END;
/

4). How many blocks are corrupt, including repair-action.

SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT,

CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION
FROM REPAIR_TABLE;

5. Try to get the data from the corrupt blocks:

create table temp_DWH as
select * from DWH_TEST.DWH
where dbms_rowid.rowid_block_number(rowid) = <corrupt_block>
and dbms_rowid.rowid_to_absolute_fno (rowid, ‘DWH_TEST’,’DWH’) = <file_number>;

6. Fix it, mark the blocks as corrupt (afterwards we get the ora-1578 with a full table scan):
SET SERVEROUTPUT ON
DECLARE num_fix INT;
BEGIN
num_fix := 0;
DBMS_REPAIR.FIX_CORRUPT_BLOCKS (
SCHEMA_NAME => ‘DWH_TEST’,
OBJECT_NAME=> ‘DWH’,
OBJECT_TYPE => dbms_repair.table_object,
REPAIR_TABLE_NAME => ‘REPAIR_TABLE’,
FIX_COUNT=> num_fix);
DBMS_OUTPUT.PUT_LINE(‘num fix: ‘ || TO_CHAR(num_fix));
END;
/

7. Has the repair been done:

SELECT OBJECT_NAME, BLOCK_ID, MARKED_CORRUPT
FROM REPAIR_TABLE;

8. Find Index entries pointing to the corrupt blocks (example of tWO indexes):

SET SERVEROUTPUT ON
DECLARE num_orphans INT;
BEGIN
num_orphans := 0;
DBMS_REPAIR.DUMP_ORPHAN_KEYS (
SCHEMA_NAME => ‘DWH_TEST’,
OBJECT_NAME => ‘IND_DWH_01’,
OBJECT_TYPE => dbms_repair.index_object,
REPAIR_TABLE_NAME => ‘REPAIR_TABLE’,
ORPHAN_TABLE_NAME=> ‘ORPHAN_KEY_TABLE’,
KEY_COUNT => num_orphans);
DBMS_OUTPUT.PUT_LINE(‘orphan key count: ‘ || TO_CHAR(num_orphans));
END;
/

DECLARE num_orphans INT;

BEGIN
num_orphans := 0;
DBMS_REPAIR.DUMP_ORPHAN_KEYS (
SCHEMA_NAME => ‘DWH_TEST’,
OBJECT_NAME => ‘IND_DWH_02’,
OBJECT_TYPE => dbms_repair.index_object,
REPAIR_TABLE_NAME => ‘REPAIR_TABLE’,
ORPHAN_TABLE_NAME=> ‘ORPHAN_KEY_TABLE’,
KEY_COUNT => num_orphans);
DBMS_OUTPUT.PUT_LINE(‘orphan key count: ‘ || TO_CHAR(num_orphans));
END;
/
9. Let Oracle skip the corrupt blocks:
BEGIN
DBMS_REPAIR.SKIP_CORRUPT_BLOCKS (
SCHEMA_NAME => ‘SCOTT’,
OBJECT_NAME => ‘DEPT’,
OBJECT_TYPE => dbms_repair.table_object,
FLAGS => dbms_repair.skip_flag);
END;
/

10. Rebuilds the free_list:

declare
begin
dbms_repair.rebuild_freelists (
schema_name => ‘DWH_TEST’,
object_name => ‘DWH’,
object_type => dbms_repair.table_object);
end;
/

11. Rebuild the indexes, which are recorded in ORPHAN_KEY_TABLE.

alter index IND_DWH_01 rebuild ONLINE;
alter index IND_DWH_02 rebuild ONLINE;

Sources:

Note.28814.1 Ext/Pub Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g P1-914CU.

RDBMS.CO-3-2 RDBMS.CO RDBMS.CO :
Note.68013.1 Ext/Pub DBMS_REPAIR example
Note 285586.1 – ORA-600 [kdsgrp1]
Note 468883.1 – ORA-600 [kdsgrp1]