相关内容

Symptoms:

Related To:

• Corruption (Logical)
• Hang (Involving Shared Resource)
• Internal Error May Occur (ORA-600)
• Wrong Results
• Error May Occur
• ORA-8102 / ORA-8103 / ORA-1410 / ORA-752
• ORA-600 [3020]
• ORA-600 [kdsgrp1]
• ORA-600 [25027]
• ORA-600 [qertbFetchByRowID]
• ORA-600 [kcbz_check_objd_typ_3]
• ORA-600 [kclchkblk_3]
• ORA-600 [4137]
• ORA-600 [4193]
• ORA-600 [4194]
• ORA-600 [6102]

• Direct NFS (dNFS)

Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:           

  This article discusses the internal error "ORA-600 [4193]", what

  it means and possible actions. The information here is only applicable

  to the versions listed and is provided only for guidance.

ERROR:             

  Format: ORA-600 [4193] [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 block sequence number in the undo block against

  the Redo block sequence number relating to the change being applied.

  This error is reported when this validation fails.

ARGUMENTS:

  Arg [a] Undo record seq number

  Arg [b] Redo record seq number

FUNCTIONALITY:

  KERNEL TRANSACTION UNDO

IMPACT:

  PROCESS FAILURE

  POSSIBLE ROLLBACK SEGMENT CORRUPTION

SUGGESTIONS:       

  This error may indicate a rollback segment corruption.

  This may require a recovery from a database backup depending on

  the situation.

  For further analysis, please submit the trace files and alert.log to

  Oracle Support Services.

  Known Issues:

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
            

The list below is restricted to show only bugs believed to affect version 11.2.0.1.
Other bugs may affect this version but have not been confirmed as being relevant yet.

There are 2 bugs listed.

·         '*' indicates that an alert exists for that issue.

·         '+' indicates a particularly notable issue / bug.

·         See Note:1944526.1 for details of other symbols used

NOTE:146580.1 - What is an ORA-600 Internal Error?
NOTE:8240762.8 - Bug 8240762 - Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] / SMON may spin to recover transaction

Bug 21977392 - ORA-600 [4193] ORA-600 [ktbair1] ORA-600 [1234] ORA-600 [6856] block type 'ktu undo block' on recovery of encrypt datafile (文档 ID 21977392.8)

转到底部

Bug 21977392  ORA-600 [4193] ORA-600 [ktbair1] ORA-600 [1234] ORA-600 [6856] block type 'ktu undo block' on recovery of encrypt datafile

 This note gives a brief overview of bug 21977392. 
 The content was last updated on: 18-APR-2016
 Click here for details of each of the sections below.

Affects:

Fixed:

Interim patches may be available for earlier versions - click here to check.

Description

This bug is only relevant when using Transparent Data Encryption

Media recovery crashes in a redo callback routine with some ORA600.

 The errors are usually ORA-600 [4193] and/or ORA-600 [ktbair1] or 

  ORA-600 [1234] ORA-600 [6856].

Rediscovery Notes

- Media recovery crashes in a redo callback routine with some ORA600.

- The errors are usually ORA-00600:[4193] and/or ORA-00600:[ktbair1].

- The ORA-600 [4193] has these characteristics:

     - ORA-10560: block type 'KTU UNDO BLOCK'

     - ORA-600 [4193] in parallel recovery slave

     - call stack:

        -> ksvrdp -> krp_slave_main -> krp_slave_apply ->

          -> kcbr_media_apply -> kcbr_apply_change ->

           -> kcoapl -> kturdb -> ORA-00600:[4193]

     - the ORA-600 incident tracefile shows a dump of the ktudb

       from the redo change vector, and all the contents look

       like garbage, eg the "flg" field has bits set other than

       these bits: 0x1FFF for example:

       ----

       *** ktuc_diag_dmp: dump of current change vector

       ktudb redo: siz: 45736 spc: 47634 flg: 0x2740 seq: 0x6253 rec: 0x7f

                  xid:  0xd29a.4e93.24dbeb07

       Unexpected kcocv element following ktudb structure:

       ----

       this is also the case for ORA-600 [1234].

     - the ORA600 incident tracefile also shows the details of the

       block involved:

       *** ktuc_diag_dmp: dump of buffer cache for rdba 0x010a63c2

       and there will be a redo dump started but it may not be

       complete, eg:

         DUMP REDO

          Opcodes *.*

          DBAs (file#, block#):

          (4, 680898) .

     - if the redo dumps shows the problematic change vector header,

       then it will be encrypted (ENC:1).

- The ORA-00600:[ktbair1] has these characteristics:

     - ORA-00600:[ktbair1] in parallel recovery slave

     - call stack:

        -> ksvrdp -> krp_slave_main -> krp_slave_apply ->

          -> kcbr_media_apply -> kcbr_apply_change ->

           -> kcoapl -> kdxlup -> ktbair2 -> ORA600:[ktbair1]

     - the ORA600 tracefile shows the dump of the problematic change

       vector header, and it is encrypted (ENC:1), eg:

        Error 600 in redo application callback:

          Dump of change vector:

          CON_ID:0 TYP:0 CLS:1 AFN:7 DBA:0x034cd2b9 OBJ:166589

            SCN:0x0000.17a2e5a8 SEQ:1 OP:10.18 ENC:1 RBL:0 FLG:0x0000

          index redo (kdxlup): update keydata, count=2

          KTB Redo

          op: 0x0e  ver: 0x00

          compat bit: 0 (pre-11) padding: 0

          op: [ktbdir] invalid op: 0x0e

       and there will be a redo dump started but it may not be

       complete, eg:

         DUMP REDO

          Opcodes *.*

          DBAs (file#, block#):

          (7, 55366329) .

        this is also the case for ORA-600 [6856]

- the database is using encryption

- dump the redo manually for the specific block involved:

    - see the incident tracefile DUMP REDO, DBAs to find the file#

      and block# to dump

    - see the alert log to find which log was being applied at the

      time of the OR6000 - this is the logfile to dump

   syntax:

   alter session set "_sga_clear_dump"=TRUE;

   alter system dump logfile ''

    dba min   dba max  ;

   the redo dump should confirm the problematic change vector is

   encrypted (ENC:1), and

   the redo dump should confirm the problematic change vector is

   very near to the start of the log - this is a very important

   characteristic of this bug, if the problematic change vector

   is NOT near to the start of the log, then it's unlikely that

   this bug is involved.

  note: this redo dump needs to be done on the customer system

         because the encryption wallet (and its password) is

        needed to decrypt the encrypted change vector data.

Workaround

 If problem is encountered in a physical standby database,

 refresh the affected files from the primary database 

Note:

 Any patch/fix for this bug will *not* "repair" already badly encrypted redo.

References

Bug:21977392 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article