Oracle ORA-00600 6002 Error Resolution

The following are the most recent errors encountered in user data recovery:

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 The body SYS. Dbms_ha_alerts_prvt
57CCE5A18 552 Package The body SYS. Dbms_ha_alerts_prvt

Error reality, there is a problem executing the internal task of the SYS.DBMS_HA_ALERTS_PRVT package.
The ORA-00600 6002 error is related to the index, and the specific content refers to:
When Oracle attempts to insert an index key value, first need to find the appropriate location, and to do the relevant checksum, checksum content including the number of indexed columns, data size, and so on, once found inconsistent, will appear ORA-600 6002 error.

The MoS explanation is as follows:

Oracle is trying to insert a key and key data into a B*tree index.
In ' order ' to ' do ', it had to the correct leaf blocks to do the insert.
Once the correct leaf block is retrieved, Oracle validates the blocks by checking the data size and number of columns in T He key.
If there is a mismatch then ORA-600 [6002] is reported.

Its main parameter meaning is as follows:

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

So if you encounter this error, you should first find the Index object where the problem occurs, and you can try to eliminate the error effect by rebuilding the index.
The following are the header information for the error that appears in the trace file:

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

We can see that the problem object number is 22a9 and the type is the index.
The object name can be found through a database query, which is resolved by rebuilding the index:

The code is as follows

Sql> Select object_name from dba_objects where Object_id=to_number (' 22a9 ', ' xxxxx ');

object_name
--------------------------------------------------------------------------------------------------------------- ---------
Wri$_alert_threshold_log_pk

sql> ALTER index WRI$_ALERT_THRESHOLD_LOG_PK rebuild online;

Index altered.

A 6002 error needs to be analyzed based on the object's differences, which can usually be resolved through an index rebuild. Sometimes the problem appears on the IoT object, which can be resolved by backing up the data, truncate the insert-back record.

Another article

ORA-600 3020 Error, the database encountered 3020 errors when applying the archive log in recovery:

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#, block# 94633)
Ora-10564:tablespace apps_undots2
Ora-01110:data File 37

After this error, the recovery is interrupted, cannot continue, the 3020 error is explained on the Metalink, the main reason is:

This is called a ' stuck RECOVERY '.
There is a inconsistency between the information stored in the redo
And the information stored in a database block being recovered.

That is, the information recorded in the redo is not consistent with the recovered block information at the time of recovery, resulting in the recovery being unable to continue. For example, update Some records from 3 to 2, finding that the record is not 3 at all, and that recovery cannot continue.

This error may be due to an operation missing from the write redo, which may have been caused by an abnormal outage or a storage failure.
This error can is reported if any of the updates are lost for some reason.

This error, if there is no backup, the data is not particularly important, you can use some implicit parameters or coercion to open the database, but inevitably there will be data loss, Olive did one such attempt.
The proven practical way to do this is to use:

The code is as follows
recover database [using Backup controlfile] allow 1 corruption;

Mark inconsistent blocks as corrupted, and you can then perform further recovery attempts.

This deal with this case, the final selection of incomplete recovery, record data, and sometimes give up is a kind of recovery!