Resolving ORA-600[3020] Raised During Recovery (Doc ID 361172.1)

Oracle Server - Enterprise Edition - Version 9.2.0.1 to 11.2.0.2 [Release 9.2 to 11.2]
Information in this document applies to any platform.

SYMPTOMS

Recovery session fails:

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [13204236], [1], [1],
[33082], [236], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 621324)
ORA-10564: tablespace DATA
ORA-01110: data file 3: '

CAUSE

This is stuck recovery - redo cannot be applied to a block because the scn of the block, when
read from disk is NOT the scn that we expect it to be.

SOLUTION

If the affected file belongs to SYSTEM or UNDO tablespace you should restore  the database from backup and do point in time recovery to just before the problem log is applied. 

If you do not have a backup available, than the options are VERY limited. Please open a Service Request with Oracle Support Services for assistance on this.

If the affected file belongs to SYSAUX, this is the ONLY file affected and it is offline then a better option than point in time recovery of the whole database would be to create a NEW database and then use Transportable Tablespace feature to plug in all other tablespaces.  Another point worth noting:  if SYSAUX is ONLINE but contains corrupt blocks, then before considering restore and recovery, use the SQL in point 3 below to identify the affected object  and raise a call with Oracle Support Services to ask if  it is possible to drop and recreate the object  (unpublished Note 333665.1).

For Data Guard environments, refer to Note:1265884.1

Otherwise:

1. Use Trial Recovery to determine the extent of the problem:

SQL> recover database test;

This will tell you how many blocks (n) would be left corrupted after recovery - check the alert
log for details of the blocks affected.  If there are a large number of corruptions reported you may decide to restore from backup and issue point in time recovery.  However, if only a few blocks are reported as corrupt you could proceed with recovery :

2. Skip the corrupted block(s)

SQL> recover database allow 1 corruption;

Do this times,  being the number of blocks reported as corrupt in step 1 above.

This will allow recovery to continue,  'skipping' the blocks that cannot be recovered and leaving them marked as 'corrupt' after which the database can be opened.

3. Take the corrupt blocks reported in the alert log and for each,  identify the object that the block belongs to::

SQL> SELECT tablespace_name, segment_type, owner, segment_name
     FROM dba_extents
     WHERE file_id =
       and between block_id AND block_id + blocks - 1;

Replacing and with the file# and block ids reported in the alert log.

For each object identified - take steps to resolve the corruption:

- if it belongs to an index then simply drop and recreate the index

- if it belong to a user object then consider recreating the object or extracting what you can from the object; if necessary raise a Service Request with Oracle and request assistance with extracting data from a corrupt object. 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15747463/viewspace-769595/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15747463/viewspace-769595/