Resolving ORA-600[3020] Raised During Recovery (Doc ID 361172.1) | 编辑To Bottom |
In this Document
APPLIES TO:Oracle Database Exadata Cloud Machine - Version N/A and laterOracle Cloud Infrastructure - Database Service - Version N/A and later Oracle Database Exadata Express Cloud Service - Version N/A and later Oracle Database Cloud Exadata Service - Version N/A and later Oracle Database Cloud Schema Service - Version N/A and later Information in this document applies to any platform. SYMPTOMSRecovery session fails:
CHANGESCAUSEThis error is referred to as stuck recovery. This error occurs when redo cannot be applied to a block because the scn of the block, when read from disk, is NOT the scn that we expect. SOLUTIONIf 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 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. For Data Guard environments, refer to Note:1265884.1 For further detail on this error and known issues, see: Note 30866.1 ORA-600 [3020] "Stuck Recovery" 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. 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 2. Skip the corrupted block(s) SQL> recover database allow 1 corruption;
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
- 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. Additional related documents : Note 1265884.1 Resolving ORA-752 or ORA-600 [3020] During Standby Recovery Note 283269.1 Stuck recovery of database ORA-00600[3020] REFERENCESNOTE:28814.1 - Handling Oracle Block Corruptions NOTE:283269.1 - Stuck recovery of database ORA-00600[3020] NOTE:1265884.1 - Resolving ORA-752 or ORA-600 [3020] During Standby Recovery NOTE:30866.1 - ORA-600 [3020] "Stuck Recovery" |