[Oracle 恢复] 怎么样恢复ORA-600 [4194]---惜分飞

在oracle恢复中ORA-600 4194是一个非常常见的错误,该错误的主要原因是由于redo记录和undo(rollback)记录不匹配.
ORA 600 4194错误原因以及含义

 
        ERROR:  
       
        Format: ORA-600 [4194] [a] [b] 
       
        VERSIONS:  
       
        versions 6.0 to 12.1  
       
        DESCRIPTION: 
       
        A mismatch has been detected between Redo records and rollback (Undo)  
       
        records. 
       
        We are validating the Undo record number relating to the change being  
       
        applied against the maximum undo record number recorded  
        in 
         the undo block. 
       
        This error is reported when the validation fails. 
       
        ARGUMENTS: 
       
        Arg [a] Maximum Undo record number  
         Undo block 
       
        Arg [b] Undo record number from Redo block

ORA 600 4194 错误处理思路
第一步

Confirm whether the database is up and running or not. If the database fails to start or crashes shortly

 
        after startup due to this error occurring, 
        then 
         try setting event 10513 at level 2  
         the init.ora 
        /spfile 
       

 
        to disable transaction recovery and restart the instance,e.g.: 
       

 
        event =  
        "10513 trace name context forever,level 2"

 
        This may allow the database to successfully  
        open 
         and stay up so that  
       

 
        the required diagnostics 
        /actions 
         can be performed. 
       

第二步

 
  In the trace file there should be an undo segment header dump,and so check  
        to see  
        if 
         the undo segment header shows an active transaction after recovery,e.g.: 
       
        TRN TBL <---- Represents the Transaction table  
        for 
         the particular undo segment 
       
        index state cflags wrap 
        # uel scn dba 
       
        ---------------------------------------------------------------------------------------------  
       
        0x41 9 0x80 0x35ab6 0xffff 0x0695.38f6b959 0x1081e796  
       
        0x42 9 0x80 0x35bb1 0x000e 0x0695.38f6b028 0x1081e793  
       
        0x43 9 0x80 0x35b11 0x005d 0x0695.38f6b7ae 0x1081e795  
       
        0x44 9 0x80 0x359f0 0x0036 0x0695.38f69a91 0x1081e78e  
       
        0x45 10 0x80 0x35b1b 0x0000 0x0695.3a0aba4d 0x1081e796  
       
        0x46 9 0x80 0x35bb7 0x001c 0x0695.38f69bde 0x1081e78f  
       
        =================================== 
       
        State ---> This column specifies the status of the transaction  
       
        9 -----> represents a commited transaction 
       
        10 ---> Represents a active transaction 
       
        Dba -----> Undo block containing the undo records 
       
        Strictly speaking this is the block at the end of the undo chain. 
       
        You can see from the transaction table that there is an active transaction  
       
         this particular rollback 
        /undo 
         segment after recovery. 
       
        Therefore this rollback 
         segment and 
        /or 
         undo tablespace cannot be dropped without corrupting the database!  
       
        Therefore recreating the UNDO tablespace is not an option.

第三步

From the trace determine the affected undo segment,e.g.:

 
        Block image after block recovery: 
       

 
        UNDO BLK:  
       

 
        xid: 0x0015.02b.0001544b  
        seq 
        : 0x163e cnt: 0x12 irb: 0x12 icl: 0x0 flg: 0x0000 
       

 
        XID ==> Undo segment no + Slot no + Sequence no 
       

 
        Therefore,monospace!important; bottom:auto!important; float:none!important; height:auto!important; left:auto!important; line-height:1.1em!important; outline:0px!important; overflow:visible!important; position:static!important; right:auto!important; top:auto!important; width:auto!important; direction:ltr!important; display:inline!important"> this  
        case 
         the Undo Segment is: 
       

 
        USN 
        # 0x15 (Hex) ==> 21 (Dec) ==> _SYSSMU21$

 
        So  
         and ONLY IF the transaction table shows no active transaction can the

 
        rollback 
         segment be offlined and dropped.Note however,

 
        that before you can confirm  
         the entire UNDO tablespace can be dropped,you would need to check the

 
        transaction tables of ALL active rollback 
         segments  
         the same wasy as the above.  
       

 
        The steps required to drop the rollback 
         segment are fully detailed  
         Note:179952.1, 
       

 
        but are briefly listed here  
         completeness:

 
        If using Automatic Undo Management 
       

 
        Offline the undo segment using the _OFFLINE_ROLLBACK_SEGMENTS parameter and bounce the database as follows: 
       

 
        1. Create and edit the init.ora  
        file 
         for 
         the instance to  
        set 
         the following parameters: 
       

 
        UNDO_MANAGEMENT=MANUAL  
       

 
        _OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU21$) 
       

 
        2. Open the database  
         restricted mode to prevent user access,e.g.:

 
        connect / as sysdba 
       

 
        startup restrict pfile =  
        '<Full path to init.ora file>' 
        ; 
       

 
        3. Drop the rollback 
         segment,e.g.:

 
        drop rollback segment  
        "_SYSSMU21" 
        ; 
       

 
        4. Shutdown the instance,and remove the init.ora parameters added  
         point 1 and restart the instance,e.g.:

 
        shutdown 
         immediate

 
        startup 
       

 
        If SMON was recovering the transaction  
         this may not work as we cannot  
         the database  
         it is determined  
       

 
        to be  
         an inconsistent state. I have reviewed a number of SRs where this approach was successful,

 
        so it is important to try it first but understand that it may fail and you will have to resort to  
       

 
        a point  
        in 
         time 
         recovery or forcing  
         the DB and recreating it. 
       

第四步

Now we need to dump the undo block to see which object was affected.

 
        We noted  
         Step 2 that this is the active transaction (from the trace  
        ):  
       

 
        TRN TBL  
       

 
        # uel scn dba  
       

 
        0x45 10 0x80 0x35b1b 0x0000 0x0695.3a0aba4d 0x1081e796  
       

 
        Dba----------------> Undo block containing the undo records  
       

 
        dba--->0x1081e796 is the block containing the active transaction .  
       

 
        Use the WebIV tools to convert this RDBA to block number (block 
        #) and file number (file#),e.g.:

 
        V SPLIT ==> DBA (Hex) = File 
        #,Block# (Hex File#,Block#)

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

 
        V8 10,10 ==> 276948886 (0x1081e796) = 66,124822 (0x42 0x1e796)  
       

 
        So the  
        file 
        # is 66 and the block# is 124822,so dump the block by issuing:  
       

 
        sql> Alter system dump datafile 66 block 124822;  
       

 
        This will generate a trace  
         in 
         the user_dump_dest. The following is a sample of the information  
         the undo block: 
       

 
        UNDO BLK:  
       

 
        xid: 0x000c.045.00035b1b  
        : 0x1e14 cnt: 0x17 irb: 0x17 icl: 0x0 flg: 0x0000

 
        Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset  
       

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

 
        0x01 0x1f8c 0x02 0x1f30 0x03 0x1ed4 0x04 0x1e78 0x05 0x1e1c  
       

 
        0x06 0x1dc0 0x07 0x1d64 0x08 0x1d08 0x09 0x1cac 0x0a 0x1c50  
       

 
        0x0b 0x1bf4 0x0c 0x1b98 0x0d 0x1b3c 0x0e 0x1ae0 0x0f 0x1a74  
       

 
        0x10 0x1a18 0x11 0x19bc 0x12 0x1960 0x13 0x1904 0x14 0x187c  
       

 
        0x15 0x181c 0x16 0x1798 0x17 0x173c  
       

 
        * Rec  
        #0x16 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)

 
        * Layer: 11 (Row) opc: 1 rci 0x00  
       

 
        Undo  
        type 
        : Regular undo Begin trans Last buffer  
        split 
        : No  
       

 
        Temp Object: No  
       

 
        Tablespace Undo: No  
       

 
        rdba: 0x00000000  
       

 
        *-----------------------------  
       

 
        uba: 0x1081e796.1e14.14 ctl max scn: 0x0695.38f69853 prv tx scn: 0x0695.38f698a1  
       

 
        KDO undo record:  
       

 
        KTB Redo  
       

 
        op 
        : 0x04 ver: 0x01

 
        : L itl: scn: 0x0019.009.00034237 uba: 0x36c0cce4.1d2f.19  
       

 
        flg: C--- lkc: 0 scn: 0x0695.38f6b96b  
       

 
        KDO Op code: URP xtype: XA bdba: 0x35406893 hdba: 0x35406892  
       

@H_301_747@ itli: 1 ispac: 0 maxfr: 4863

 
        tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0  
       

 
        ncol: 1 nnew: 1 size: -1  
       

 
        col 0: [ 4] c3 0e 36 2e  
       

 
        *-----------------------------  
       

 
        #0x17 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)  
       

 
        * Layer: 11 (Row) opc: 1 rci 0x16  
       

 
        : Regular undo Last buffer  
        : No

 
        Temp Object: No  
       

 
        Tablespace Undo: No  
       

 
        rdba: 0x00000000  
       

 
        *-----------------------------  
       

 
         above: 
       

 
        UNDO BLK:  
       

 
        : 0x1e14 cnt: 0x17 irb: 0x17 icl: 0x0 flg: 0x0000 
       

 
        The undo segment with the active transaction is segment is 0x000c (Hex)  
         is 12 (Dec) as the XID is:

 
        Undo segment no + Slot no + Sequence no 
       

 
        This step is often skipped because it was performed earlier  
         step 3,however it is a good idea to  
        do 
         this  
       

 
        again now to  
        make 
         sure that the XID from the UNDO block matches the UNDO SEGMENT HEADER, 
       

 
        this way you have followed all the chain,from the UNDO SEGMENT to UNDO BLOCK,back and forth.  
       

 
        If there is a conflict here please check and  
         sure that the customer dumped the correct undo block.

 
        Check  
         the value of irb  
         is an index  
         points you to the latest change  
        done 
         to the undo block. 
       

 
        This is the point from  
         a rollback would begin  
         one was issued. 
       

 
         we see:  
        'irb: 0x17' 
         so this points to record 0x17, 
       

 
        so search  
         this particular string i.e 0x17 and it will take you to undo record  
        'REC #0x17' 
        ,e.g.: 
       

 
        #0x17 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)  
       

 
        * Layer: 11 (Row) opc: 1 rci 0x16  
       

 
        : No  
       

 
        Temp Object: No  
       

 
        Tablespace Undo: No  
       

 
        rdba: 0x00000000  
       

 
        *-----------------------------  
       

 
        Note the slot number (slt) is 0x45,the object number (objn) is the OBJECT_ID from dba_objects  
       

 
        and data object number (objd) is the DATA_OBJECT_ID from dba_objects.  
       

 
        These numbers may be the same but not necessarily,and so  
         the database is  
        open 
         then 
         identify this object,e.g.: 
       

 
        select 
         object_name,owner,object_type,data_object_id from dba_objects where object_id = <objn>;

 
        This is the object, 
         has an active transaction. Note  
         the above trace  
         extract that rci  
       

 
        has a value of 0x16  
         means that this record is at the end of an undo chain.

 
        This means that the chain continues  
         another UNDO BLOCK.

 
        Please refer to unpublished Note:281504.1  
         information on Undo chains.

 
        So the next record that needs to be rolled back is present  
         REC  
        #X016.  
       

 
        If rci is 0x00  
         it means that this is the first record present  
         the undo chain  
       

 
        and so you can check to see  
         there is rdba info,e.g.:

 
        #0x16 slt: 0x45 objn: 1485619(0x0016ab33) objd: 1485619 tblspc: 71(0x00000047)  
       

 
        * Layer: 11 (Row) opc: 1 rci 0x00  
       

 
        : No  
       

 
        Temp Object: No  
       

 
        Tablespace Undo: No  
       

 
        rdba: 0x00000000  
       

 
        *-----------------------------  
       

 
        uba: 0x1081e796.1e14.14 ctl max scn: 0x0695.38f69853 prv tx scn: 0x0695.38f698a1  
       

 
        KDO undo record:  
       

 
        KTB Redo  
       

 
        : 0x04 ver: 0x01  
       

 
        : L itl: scn: 0x0019.009.00034237 uba: 0x36c0cce4.1d2f.19  
       

 
        flg: C--- lkc: 0 scn: 0x0695.38f6b96b  
       

 
        KDO Op code: URP xtype: XA bdba: 0x35406893 hdba: 0x35406892  
       

 
        itli: 1 ispac: 0 maxfr: 4863  
       

 
        tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0  
       

 
        ncol: 1 nnew: 1 size: -1  
       

 
        col 0: [ 4] c3 0e 36 2e  
       

 
        *-----------------------------  
       

 
        If the object is an Index,drop and recreate it. If it is a table, 
       

 
         again the table would need to be dropped and recreated (or truncated)  
       

 
        so that its object number changes and hence the rollback 
         is no longer required.

 
        If this isn't possible,monospace!important; bottom:auto!important; float:none!important; height:auto!important; left:auto!important; line-height:1.1em!important; outline:0px!important; overflow:visible!important; position:static!important; right:auto!important; top:auto!important; width:auto!important; direction:ltr!important; display:inline!important"> you have two options: 
       

 
        First take a backup of the database  
         its current state.

 
        This is critical  
        in 
         case 
         anything goes wrong and you lose the opportunity to salvage the data!  
       

 
        Option 1 
       

@H_403_1145@

 
        - Restore the undo segment datafile and the datafile containing the object and perform a full recovery. 
       

 
        This can only be  
        done 
         if 
         you have all the archived redo as you will need to  
         full recovery on these files. 
       

OR

 
        Option 2 
       

 
        If option 1 is not possible,you can use the unsupported method,e.g.: 
       

 
        Specify the undo segment  
         the _OFFLINE_ROLLBACK_SEGMENTS parameter and try to drop the rollback segment.

 
        If there is an active transaction  
         this is not likely to work and you will probably need

 
        to  
         the _CORRUPTED_ROLLBACK_SEGMENTS parameter as well

温馨提示： 1.隐含参数_OFFLINE_ROLLBACK_SEGMENTS/_CORRUPTED_ROLLBACK_SEGMENTS属于Oracle内部隐含参数,建议在Oracle support认可的情况下使用,因为使用之后可能导致数据库事务完整性彻底损坏 2.进行屏蔽事务之前,如果条件允许建议使用txchecker检查 2.使用上述方法恢复数据库之后，建议通过逻辑方式导出导入重建数据库

原文链接：https://www.f2er.com/oracle/211983.html

[Oracle 恢复] 怎么样恢复ORA-600 [4194]---惜分飞

猜你在找的Oracle相关文章