ORA-00600[kcratr1_lostwrt]/ORA-00600[3020]错误恢复

《ORA-00600[kcratr1_lostwrt]/ORA-00600[3020]错误恢复》有 4 条评论

1. 惜分飞 说：

   2013 年 4 月 23 日18:32

   600[3020]恢复过程alert日志记录

   Mon Apr 22 21:53:41 2013
   alter database recover if needed
    datafile 1055 allow 1 corruption
   Media Recovery Start
    ALLOW CORRUPTION option must use serial recovery
   Mon Apr 22 21:53:41 2013
   Recovery of Online Redo Log: Thread 2 Group 8 Seq 54321 Reading mem 0
     Mem# 0: +DATA/q9dbdg/onlinelog/redo08.log
   Mon Apr 22 21:53:41 2013
   Recovery of Online Redo Log: Thread 1 Group 2 Seq 53587 Reading mem 0
     Mem# 0: +DATA/q9dbdg/onlinelog/redo02.log
   CORRUPTING BLOCK 456338 OF FILE 1055 AND CONTINUING RECOVERY
   Mon Apr 22 21:53:42 2013
   Errors in file /u01/oracle/app/admin/q9db/udump/q9db1_ora_12223.trc:
   ORA-10567: Redo is inconsistent with data block (file# 1055, block# 456338)
   ORA-10564: tablespace PART_DATA
   ORA-01110: data file 1055: '+DATA03/q9dbrac/datafile/part_data583.dbf'
   ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 121354
   Mon Apr 22 21:53:42 2013
   Recovery of Online Redo Log: Thread 1 Group 3 Seq 53588 Reading mem 0
     Mem# 0: +DATA/q9dbdg/onlinelog/redo03.log
   Mon Apr 22 21:53:42 2013
   Media Recovery Complete (q9db1)
   Completed: alter database recover if needed
    datafile 1055 allow 1 corruption
   Mon Apr 22 21:53:56 2013
   alter database datafile 1055 online
   Mon Apr 22 21:53:56 2013
   Completed: alter database datafile 1055 online
   
2. 惜分飞 说：

   2012 年 5 月 15 日22:34

   Applies to:
   Oracle Server - Enterprise Edition - Version: 9.0.1.4 to 9.2.0.8
   This problem can occur on any platform.
   
   Symptoms
   False ORA-600[kcratr1_lostwrt] (on 9.2) or ORA-397 (on 9.0) can happen
   during crash recovery or thread recovery in RAC system.
   If problem happen during crash recovery at starting up database, Oracle
   can't startup database. If problem happen during thread recovery, all RAC
   node might crash.
   
   You will see following log at terminal if problem happen at crash recovery.
   SQL> connect / as sysdba
   Connected to an idle instance.
   SQL> startup
   ORACLE instance started.
   Total System Global Area 72831496 bytes
   Fixed Size 455176 bytes
   Variable Size 62914560 bytes
   Database Buffers 8388608 bytes
   Redo Buffers 1073152 bytes
   Database mounted.
   ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [],[], [], []
   
   If problem happen at thread recovery, you will see SMON error in alert.log
   Tue Oct  2 16:41:26 2007
   Instance recovery: looking for dead threads
   Tue Oct  2 16:41:26 2007
   Beginning instance recovery of 1 threads
   Tue Oct  2 16:41:26 2007
   Started redo scan
   Tue Oct  2 16:41:26 2007
   Errors in file /app/oracle/product/9.2.0/admin/ora920/bdump/ora920_smon_12345.trc:
   ORA-00600: internal error code, arguments: [kcratr1_lostwrt], [], [], [], [], [], [], []
   
   Cause
   Oracle signals this error during first pass of two pass recovery if it finds
   lost write. Two pass recovery is a new feature in Oracle 9i, and gives
   performance improvement on crash and thread recovery.
   
   In first pass of two pass recovery, Oracle read redo stream and construct
   list of blocks which need to be recovered. For this feature, DBWR writes
   BWR (Block Written Record) to redo stream to tell it has written a change
   to disk, and that change does not need to be applied during crash recovery.
   At the end of first pass, Oracle compares SCN (System Change Number)
   in the last BWR and SCN on the disk to verify changes in the last BWR is
   actually written to disk.
   
   But Oracle may signal false lost-write error on temporary block.
   This problem can happen if someone manages temporary object including
   temporary table, sort block, etc around the time database aborted.
   
   As an example, we may encounter problem when we shutdown abort database
   after using dbms_stats.gather_schema_stats (which use temporary table and
   sort operation to gather statistics)
   
   Solution
   
   First determine if this error is signaled on temporary block or not.
   Trace file written by this ORA-600 or ORA-397 has following entry at
   the beginning part of trace file before showing ORA- error message.
   
   Last BWR afn: 201 rdba: 0x400123(blk 291) ver: 0x0000.12345678.00 flg: 0x0c
   Disk version: 0x0000.00000000.01 flag: 0x0c
   
   Check values at flg: and flag: and change it to binary, if either or both have
   0x08 = 00001000 bit, you hit this false error problem.
   In above example, both flg: and flag: = 0x0c = 00001100, so it hit problem.
   
   If you hit this false error, add following as initialization parameter and then
   shutdown and restart database.
   _two_pass = FALSE
   With this parameter, Oracle doesn't use two pass recovery feature and we can
   complete crash recovery.
   Once database startup successfully, remove _two_pass parameter, then shutdown
   normal and startup database. You should configure this parameter only when you
   need to resolve this issue.
   
3. 惜分飞 说：

   2012 年 5 月 15 日22:30

   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.
   
4. 惜分飞 说：

   2012 年 5 月 15 日22:23

   ORA-600 [3020] “Stuck Recovery” [ID 30866.1]

   Applies to:
   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: '<dir>/PROD_Data01.dbf'
   ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 25535
   
   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 <n> times,  <n> 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 = <file#>
          and <block> between block_id AND block_id + blocks - 1;
   
   Replacing <file#> and <block> 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. 
   
    
   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]