The social network for Oracle people

ORa-600

we are getting the below error in Production database.

production database.

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcb_pre_apply_1], [19608], [], [], [], [], [], []
Current SQL statement for this session:
DELETE FROM JMS_MESSAGES WHERE TXID=:1 AND TXOP=:2

In Standby database(data guard)

Errors in file /u02/oradata/RP01/data1/dumps/bdump/rp02_mrp0_25421.trc:
ORA-00600: internal error code, arguments: [3020], [291], [2299581], [1], [7877], [32953], [148], []
ORA-10567: Redo is inconsistent with data block (file# 291, block# 2299581)
ORA-10564: tablespace BOTTO
ORA-01110: data file 291: '/u02/oradata/RP01/data2/data/botto_064.dbf'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 127260

KCOX_FUTURE: CHANGE IN FUTURE OF BLOCK
*** 2010-02-02 18:14:48.233
RECOVERY STUCK AT BLOCK 2299581 OF FILE 291

Due to Above errors our standby database is out of sync ,it was happened for thrice in last 3 months.

so please suggest how to resolve this error

Regards,

Rajesh

Comment by Rajeev K on February 17, 2010 at 5:26am: This error occurs due to sudden system failure.We need to check log files (trc) to find out data block which is corrupted.

Comment by Nazim Merchant on March 2, 2010 at 1:20am: According to metalink ... (note: depends on version of your database)

ERROR:
ORA-600 [3020] [a] [b] [c] [d] [e]

VERSIONS:
version 6.0 to 10.1

DESCRIPTION:

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.

ARGUMENTS:

For Oracle 9.2 and earlier:
Arg [a] Block DBA
Arg [b] Redo Thread
Arg [c] Redo RBA Seq
Arg [d] Redo RBA Block No
Arg [e] Redo RBA Offset.

For Oracle 10.1
Arg [a] Absolute file number of the datafile.
Arg [b] Block number
Arg [c] Block DBA

FUNCTIONALITY:
kernel cache recovery parallel

IMPACT:
INSTANCE FAILURE during recovery.

SUGGESTIONS:

There have been cases of receiving this error when RECOVER has
been issued, but either some datafiles were not restored to disk,
or the restoration has not finished.

Therefore, ensure that the entire backup has been restored and that
the restore has finished PRIOR to issuing a RECOVER database command.

If problems continue, consider restoring from a backup and doing a
point-in-time recovery to a time PRIOR to the one implied by
the ORA-600[3020] error.

Example:

SQL> recover database until time 'YYYY-MON-DD:HH:MI:SS';

This error can also be caused by a lost update.

During normal operations, block updates/writes are being performed to
a number of files including database datafiles, redo log files,
archived redo log files etc.

This error can be reported if any of these updates are lost for some
reason.

Therefore, thoroughly check your operating system and disk hardware.

In the case of a lost update, restore an old copy of the datafile and
attempt to recover and roll forward again.