zoukankan      html  css  js  c++  java
  • Step by step to resolve ORA-600 4194 4193 4197 on database crash (Doc ID 1428786.1)

    To BottomTo Bottom

    In this Document

      Symptoms
      Changes
      Cause
      Solution
      References

    APPLIES TO:

    Oracle Database - Enterprise Edition - Version 9.2.0.1 to 12.2.0.1 [Release 9.2 to 12.2]
    Information in this document applies to any platform.
    ***Checked for relevance on 04-Dec-2013***

    SYMPTOMS

    The following error is occurring in the alert.log right before the database crashes.

    ORA-00600: internal error code, arguments: [4194], [#], [#], [], [], [], [], []

    This error indicates that a mismatch has been detected between redo records and rollback (undo) records.

    ARGUMENTS:

    Arg [a] - Maximum Undo record number in Undo block
    Arg [b] - Undo record number from Redo block

    Since we are adding a new undo record to our undo block, we would expect that the new record number is equal to the maximum record number in the undo block plus one. Before Oracle can add a new undo record to the undo block it validates that this is correct. If this validation fails, then an ORA-600 [4194] will be triggered.

    CHANGES

    This issue generally occurs when there is a power outage or hardware failure that initially crashes the database. On startup, the database does the normal roll forward (redo) and then rollback (undo), this is where the error is generated on the rollback.

    CAUSE

    This also can be cause by the following defect

    Bug 8240762 Abstract: Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] after SHRINK

    Details:
    Undo corruption may be caused after a shrink and the same undo block may be used
    for two different transactions causing several internal errors like:
    ORA-600 [4193] / ORA-600 [4194] for new transactions
    ORA-600 [4137] for a transaction rollback

    This Bug is 

    Fixed in Releases:     10.2.0.5 11.1.0.7.10 11.2.0.1 WIN:A204P40 WIN:B107P42

    SOLUTION

    Best practice to create a new undo tablespace.
    This method includes segment check.

    1. Create pfile from spfile to edit
    SQL> Create pfile='/tmp/initsid.ora' from spfile;

    2. Shutdown the instance

    3. set the following parameters in the pfile /tmp/initsid.ora
        undo_management = manual
        event = '10513 trace name context forever, level 2'

    4. SQL>>startup restrict pfile='/tmp/initsid.ora'

    5. SQL>select tablespace_name, status, segment_name from dba_rollback_segs where status != 'OFFLINE';

    This is critical - we are looking for all undo segments to be offline - System will always be online.

    If any are 'PARTLY AVAILABLE' or 'NEEDS RECOVERY' - Please open an issue with Oracle Support or update the current SR.  There are many options from this moment and Oracle Support Analyst can offer different solutions for the bad undo segments.

    If all offline then continue to the next step

    6. Create new undo tablespace - example
    SQL>create undo tablespace <new undo tablespace> datafile <datafile> size 2000M;

    7. Drop old undo tablespace
    SQL>drop tablespace <old undo tablespace> including contents and datafiles;

    8. SQL>shutdown immediate;

    9 SQL>startup nomount;  --> Using your Original spfile

    10. Modify the spfile with the new undo tablespace name

    SQL> Alter system set undo_tablespace = '<new tablespace created in step 6>' scope=spfile;

    11. SQL>shutdown immediate;

    12. SQL>startup;  --> Using spfile
     


    The reason we create a new undo tablespace first is to use new undo segment numbers that are higher then the current segments being used.  This way when a transaction goes to do block clean-out the reference to that undo segment does not exist and continues with the block clean-out.

  • 相关阅读:
    简明Secure boot介绍
    密码学有什么用?
    mkimage, no such file or dir
    嵌入式系统安全简介
    希尔排序
    jQuery选择器
    css 选择器
    安装 SQL Server 2008 和管理工具 SQL Server 2008 management studio 及相关问题解决
    mac下安装安卓开发环境
    IOS开发小记-内存管理
  • 原文地址:https://www.cnblogs.com/muzisanshi/p/13175785.html
Copyright © 2011-2022 走看看