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

VERSIONS:

version 6.0 and above 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.

If the Known Issues section below does not help in terms of  identifying a solution, please submit the trace files and alert.log to Oracle Support Services for further  analysis.

Known Issues:

Related Articles

Note:1265884.1      Resolving ORA-752 or ORA-600 [3020] During Standby  Recovery

Known Bugs

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:

It is especially useful to focus on the particular datafile block implied by the ORA-600 [3020]. Dump all redo for that block, starting with the log sequence before the restored  datafile,

up to the point of failure.

Blockdumps of the datafile should be taken at various stages of the recovery process - for example right after doing the restore; and then again after each redo log file has been applied; and just before the SCN (or point in time) that the ORA-600 was reported; and just after  redo

for the given SCN has been applied; and so  on.

The idea being that you may narrow down the point at which something went wrong.

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

Versions: 7.0.X  - 8.0.5                                  Source: knl/kcrp.c

===========================================================================

Meaning:

Recovering database and REDO entry has an INC/SEQUENCE number greater than that on the database  block.

In Oracle8 where the block structure is different it still means the same basic thing - the redo record we have has an SCN / SEQ which does not match the database block we are wanting to apply it to.

This is called 'STUCK RECOVERY'.

---------------------------------------------------------------------------

Argument Description:

a.   Block DBA

b.   Redo Thread

c.   Redo RBA Seq

d.   Redo RBA Block No

e.   Redo RBA Offset.

---------------------------------------------------------------------------

Diagnosis:

There are many possible causes for this most resulting from either invalid sets of commands or media  corruption.

-  Has customer restored a backup, open the DB, closed the DB and then tried to recover without re-loading the backup  ??

** If they say no GET THE ALERT LOG and prove it - it's easy to waste a lot of time when this was the real  cause.

-  If the problem was a lost update, restore of an OLDER copy of the datafile and a recovery may work.

-  The quick option here is to restore and recover UP TO an  SCN

just before the problem. Customer will lose some data as this is an incomplete recovery so you need to know the  priority:

a)  TIME   or  b) Minimal Data Loss.

-  Check the tracefile for the 3020 report. It is possible to signal OERI(3020) if the datafile block is  corrupt.

Eg: OERI(3020) with Inc=0 Seq=1 reported for the disk block is possibly a zeroed out data-block on the datafile and NOT a redo issue.

-  Is parallel server being used ?

If so another thread may have the required changes and they haven't been read for some reason. Check for OS and DLM errors. Try to make sure only ONE instance attempts any recovery by shutting down other instances.

-  Are hot backups being used ??

Check that the backups are occuring correctly between BEGIN and END backup commands.

-  Up to Oracle 8i you can try to skip the error using the  hidden

parameter:CORRUPT_BLOCKS_ON_STUCK_RECOVERY

Be aware that blocks will be marked corrupt if this is used so make sure the error is not on a dictionary object  !!

-  From 9i you can try to skip the error using the 'ALLOW .. CORRUPTION' clause of the RECOVER DATABASE  command.

(Note that in 11g onwards you may need to set DB_LOST_WRITE_PROTECT=NONE for the "ALLOW 1 CORRUPTION" clause to  work)

-  For logging a bug you need:

(a)  Where an error is reported, get any trace files produced and relevant redo log dumps if  necessary.

Document completely the circumstances  leading

up to the error including configuration; type of backup (manual, RMAN, incremental, etc.);

the exact commands used to create the backups  and

the exact commands used to do the restore and  recovery.

(b)  Provide a reproducible test case or dial-in information to development.

(c)  Where relevant, determine if generic or port-specific  issue.

Articles:

Parameter:CORRUPT_BLOCKS_ON_STUCK_RECOVERY

---------------------------------------------------------------------------