ORACLE 8.0.5 ORA-01207故障恢复

《ORACLE 8.0.5 ORA-01207故障恢复》有 2 条评论

1. 惜分飞 说：

   2014 年 2 月 14 日17:34

   ORA-600[4147][a][b] it’s a corruption in the undo segment. 
   Block not new enough (Undo) Sequences match but count wrong. 
   
   [a] Record number from the UBA we want to look at. 
   [b] Count on the Undo block header. 
   
   This error is raised when we are looking at a data block, and need to read the undo pointed at by the UBA(eg. for CR) but the record number from the UBA we want to look at doesn’t exist in the undo block header. 
   
   The UNDO block we are looking at is dumped to the trace file before the ORA-600[4147] and call stack. 
   
   E.g. in 10.1.0.5
   
    The undo record shows:
   
   2007-07-10 10:48:48.467 
   *** SERVICE NAME:(SYS$USERS) 2007-07-10 10:48:48.466 
   *** SESSION ID:(281.26013) 2007-07-10 10:48:48.466 
   Dump of buffer cache at level 3 
   BH (0x0x72fcbfe0) file#: 2 rdba: 0x00802fdc (2/12252) class: 42 ba: 0x0x72618000 
     set: 6 blksize: 8192 bsi: 0 set_flg: 0 pwbcnt: 0 
     dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2 
     hash: [53faf870,ac20da50] lru: [53fd885c,57fb57ec] 
     ckptq: [60fe6408,53fd8830] fileq: [77fed448,68fe2cf0] 
     use: [NULL] wait: [NULL] 
     st: XCURRENT md: NULL tch: 2 txn: 0xac793324 
     flags 0x2002009: buffer_dirty private gotten_in_current_mode redo_since_read 
     LRBA: [0xba99.1bd30.0] HSCN: [0x0.132c41a1] HSUB: [1] 
     buffer tsn: 1 rdba: 0x00802fdc (2/12252) 
     scn: 0x0000.132c41a1 seq: 0x06 flg: 0x00 tail: 0x41a10206 
     frmt: 0x02 chkval: 0x0000 type: 0x02=KTU UNDO BLOCK 
     
   ******************************************************************************** 
   UNDO BLK:   
   xid: 0x000d.024.00004a96  seq: 0x13ae cnt: 0xa   irb: 0xa   icl: 0x0   flg: 0x0000  --> cnt: 0xa   = 10 
   The problem undo segment is usn#=13(d in hex) 
   --> cnt: 0xa   = 10 means this TX has only 10 chained records 
   
    *** 2007-07-10 10:50:13.794 
   ksedmp: internal or fatal error 
   ORA-00600: internal error code, arguments: [4147], [12], [10], [], [], [], [],  
   Current SQL statement for this session: 
   UPDATE POTENTIAL_VIOS .... 
   
   Block header dump:  0x09004664 
    Object id on Block? Y 
    seg/obj: 0x17adb  csc: 0x00.132c4258  itc: 2  flg: O  typ: 1 - DATA 
        fsl: 0  fnx: 0x9004665 ver: 0x01 
     
    Itl           Xid            Uba               Flag  Lck        Scn/Fsc 
   0x01   0x000d.024.00004a96  0x00802fdc.13ae.0c  ----  1  fsc 0x0000.00000000   
   0x02   0x000d.020.00004a96  0x00802fdc.13ae.02  C---  0  scn 0x0000.132c4193 
   
    
   
   We need to update a record that is part of an uncommitted TX  
   and the changes are in Uba: 0x00802fdc.13ae.0c.    
      
   Uba is the UndoBlockAddress =   dba.seq#.rec# 
   The Uba shows rec#= 0c -> the change is in  rec chain 12,  
   however the undo header shows this TX has only 10 chain records. 
   
   Because of this mismatch we raise the ora-600[4147[12][10] 
   
2. 惜分飞 说：

   2014 年 2 月 14 日17:26

   ORA-600 [3668] “Media Recovery Required After CREATE CONTROLFILE” (Doc ID 93665.1)

   ERROR:
     ORA-600 [3668] [a] [b] [c] [d] [e]
   
   VERSIONS:
     versions 7.0 to 9.2
   
   DESCRIPTION:
   
     This is the FIRST time an attempt has been made to start an instance 
     after a CREATE CONTROLFILE command has been issued.
   
     At least one data file needs MEDIA RECOVERY.
   
     The error has been externalised in Oracle 9.2.x as :
   
         ORA-1113: file <name> needs media recovery.
   
   ARGUMENTS:
      Arg [a]  File number needing media recovery
      Arg [b]  Control file status 
      Arg [c]  Control file checkpoint count
      Arg [d]  File header checkpoint count
      Arg [e]  File header status
    
   FUNCTIONALITY:
     CACHE RECOVERY COMPONENT
    
   IMPACT:
     INSTANCE FAILURE - Usually unable to start the instance when
                        receiving this error.
    
   SUGGESTIONS:        
   
     This should only ever be signalled if a CREATE CONTROLFILE has just been 
     performed and one or more files need media recovery.
   
     In this case it is best to:
   
     o  recreate the controlfile again.
   
           Prior to doing this, check that the create controlfile statement
           is accurate in all respects.
   
           For example, check that it contains the correct number of 
           datafiles for each tablespace and that these files exist.
   
           Check that it contains the correct number of redo log groups.
   
     o  Perform the appropriate media recovery
   
            The type of recovery to be performed depends on the circumstances. 
   
            Doing a complete media recovery :
   
                RECOVER DATABASE (if create controlfile was NORESETLOGS)
                ALTER DATABASE OPEN;
   
            Doing an incomplete recovery (for example time based, change based
            or until CANCEL) :
   
                RECOVER DATABASE USING BACKUP CONTROLFILE (if using RESETLOGS)
                ALTER DATABASE OPEN RESETLOGS;
   
                You may need to supply the names of the ONLINE logs to complete 
                the 'BACKUP CONTROLFILE' recovery.