以下是最近在用户数据恢复中遇到的错误：
*** 2012-03-08 13:56:04.178
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [6002], [0], [0], [4], [0], [], [], []
----- PL/SQL Call Stack -----
object line object
handle number name
57cce5a18 418 package body SYS.DBMS_HA_ALERTS_PRVT
57cce5a18 552 package body SYS.DBMS_HA_ALERTS_PRVT
错误现实，在执行SYS.DBMS_HA_ALERTS_PRVT包的内部任务时出现问题。
而 ORA-00600 6002 错误和索引相关，具体内容是指：
当Oracle试图去插入一个索引键值时，首先需要找到合适的位置，并且去进行相关校验，校验内容包括索引列数量、数据大小等，一旦发现不一致，则将出现ORA-600 的 6002错误。
MOS上的解释如下：
Oracle was trying to insert a key and key data into a b*tree index.
In order to do this, it had to first find the correct leaf block to do the insert.
Once the correct leaf block is retrieved, Oracle validates the block by checking the data size and number of columns in the key.
If there is a mismatch then ORA-600 [6002] is reported.
其主要的参数含义如下：
Arg [a] Number of bytes in keydata
Arg [b] Number of bytes in the index layer of the leaf header
Arg [c] Number of columns in index search key structure
Arg [d] Number of columns in the index layer fo the leaf header
所以如果遇到这个错误，首先应该找到出现问题的索引对象，可以尝试通过重建索引消除这个错误影响。
如下是跟踪文件中体现的出现错误的块头信息：
Block header dump: 0x00c086ed
Object id on Block? Y
seg/obj: 0x22a9 csc: 0x00.1c87691f itc: 12 flg: E typ: 2 - INDEX
brn: 0 bdba: 0xc086e9 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000a.016.00045449 0x0080027f.4951.02 C--- 0 scn 0x0000.0b0c478c
0x02 0x0014.00e.000aadce 0x01000b9f.67ea.26 C--- 0 scn 0x0000.1c876660
0x03 0x0014.01b.000aada1 0x01000b9f.67ea.17 C--- 0 scn 0x0000.1c87653d
0x04 0x000a.002.000e628d 0x00800247.6ebe.29 C--- 0 scn 0x0000.1c87691e
0x05 0x0034.00e.00000270 0x010061c8.00c6.11 ---- 1 fsc 0x0000.00000000
0x06 0x0009.01d.0001e6dc 0x0080008a.8128.37 --U- 1 fsc 0x0031.1c876923
0x07 0x0008.017.0001d3c2 0x00800080.8857.26 C--- 0 scn 0x0000.1c87613a
0x08 0x0002.02b.0001720e 0x00801355.7ebb.1f C--- 0 scn 0x0000.1c87654d
0x09 0x000a.01f.000e6254 0x00800245.6ebe.0e C--- 0 scn 0x0000.1c87683c
0x0a 0x0009.004.0001e89d 0x0080008a.8128.30 C--- 0 scn 0x0000.1c876841
0x0b 0x000a.00a.000e6279 0x0080023f.6ebe.08 C--- 0 scn 0x0000.1c87666a
0x0c 0x000a.011.000e6252 0x0080022f.6ebe.3e C--- 0 scn 0x0000.1c87613e
我们可以看到出现问题的对象号是22a9，类型正是索引。
通过数据库查询可以找到这个对象名称,通过重建索引即可解决：
| 代码如下 | 复制代码 |
|
SQL> select object_name from dba_objects where object_id=to_number('22a9','xxxxx'); OBJECT_NAME SQL> alter index WRI$_ALERT_THRESHOLD_LOG_PK rebuild online; Index altered. |
|
6002错误需要根据对象的不同进行分析，通常是可以通过索引重建解决的。有时候问题会出现在IOT对象上，可以通过备份数据，TRUNCATE再INSERT回插记录解决。
另一篇文章
ORA-600的3020错误，数据库在故障恢复中，应用归档日志时遇到3020错误：
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement:
alter database recover logfile '/arch/prod1_2711_681480148.arc'
ORA-00283: recovery session canceled due to errors
ORA-12801: error signaled in parallel query server P011, instance hpdb1:PROD1 (1)
ORA-00600: internal error code, arguments: [3020], [37], [94633], [2], [3659], [604], [16], []
ORA-10567: Redo is inconsistent with data block (file# 37, block# 94633)
ORA-10564: tablespace APPS_UNDOTS2
ORA-01110: data file 37
出现这个错误后，恢复中断，无法继续，3020错误在Metalink上的解释，主要原因是：
This is called a 'STUCK RECOVERY'.
There is an inconsistency between the information stored in the redo
and the information stored in a database block being recovered.
也就是说，在恢复时发现Redo里面记录的信息和被恢复的数据块信息不一致，导致恢复无法继续。比如Update Some record from 3 to 2,结果发现该记录根本不是3，恢复无法继续。
这个错误可能是由于写Redo的某个操作丢失，这可能是由于异常宕机或存储故障导致的。
This error can be reported if any of these updates are lost for some reason.
出现这个错误，如果没有备份，数据也不是特别重要，则可以通过一些隐含参数或强制手段来打开数据库，不过不可避免的会出现数据损失，Olive做过一次这样的尝试 。
经过验证的可实践方式是使用：
| 代码如下 | 复制代码 |
| recover database [using backup controlfile] allow 1 corruption; | |
将不一致的块标记为损坏，然后可以执行进一步的恢复尝试。
这次处理这个案例，最后选择了不完全恢复，补录数据，有时候放弃也是一种恢复！