ORA-00600

ORA-00600

1 前言

ORA-006000 错误,一般都会涉及到Oracle 的BUG 问题。所以这种问题很难解决。这里只 能对已经发生过的,进行一些总结。以供对比和判断。如果各种条件能完全匹配,则可以 尝试进行对应方法的解决。如果条件不匹配,在购买Oracle 服务的情况下,可以申请 Oracle 支持。

另外,也有可能信息补充不及时,最好是直接到 MOS 账号上查询。

下面各个部分,以错误的第一个参数为区分点。

1.1 3020

1.2 kcblin_3

总体来说,这个参数的报错,是由于内存管理方面的问题。比如参数设置过大,或者内 存自动管理与手动管理的冲突等。

触发条件及解决方法
  1. _PGA_MAX_SIZE 设置超过2G,
    解决方法
    1. 将该参数值调整至2G,或者更低
    2. 升级至12.2
    3. 安装补丁:17951233
  2. SORT_AREA_SIZE 设置过大
    触发条件
    • 操作系统使用大页
    • 以下三个参数被设置并生效 workarea_size_policy=manual sort_area_size=2147483647 sort_area_retained_size=2147483647
    解决方法
    设置sort_area_size=2145386946 或者更小
  3. _smm_max_size 设置过大
    触发条件
    _SMM_MAX_SIZE 设置超过2G.
    解决方法
    1. 升级至12.2
    2. 安装补丁:17951233
  4. 内存参数配置冲突
    触发条件
    一方面是使用了内存的自动管理memory_target/sga_target,又手动设置了以下几个参数:
    • sort_area_size
    • hash_area_size
    • workarea_size_policy
    解决办法
    将以上三个参数去除。

1.3 kghfrunp

kghfrunp - kernel generic heap manager free unused space in a heap free unpinned space 堆管理时,用于释放未不再使用的内存空间和释放pin的空间。

1.3.1 no duration

EXPDP执行时报错ORA-00600[kghfrunp: no duration]。 当操作需要SGA释放部分领域来使用时,由于没有正常释放就会报错ORA-00600[kghfrunp]。 Bug 13914613 Excessive time holding shared pool latch in kghfrunp with auto memory management 回避策为

SQL> alter system set "_enable_shared_pool_durations"=false scope=spfile;

1.4 kdBlkCheckError

 

1.4.1 现象

在数据库宕机前出现ORA-00600错误。 日志内容如下:

ORA-01595: error freeing extent (4) of rollback segment (31))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []
Corrupt Block Found
         TSN = 2, TSNAME = UNDOTBS1
         RFN = 3, BLK = 3, RDBA = 12582915
         OBJN = 2, OBJD = -1, OBJECT = , SUBOBJECT =
         SEGMENT OWNER = , SEGMENT TYPE =
Wed Aug 02 10:00:05 2017
Dumping diagnostic data in directory=[cdmp_20170802100005], requested by (instance=1, osid=24055 (SMON)), summary=[incident=48868].
Errors in file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_smon_24055.trc  (incident=61108):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [3], [18018], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/aiboss/aiboss/incident/incdir_61108/aiboss_smon_24055_i61108.trc
Wed Aug 02 10:00:11 2017
PMON (ospid: 24025): terminating the instance due to error 474
System state dump requested by (instance=1, osid=24025 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/aiboss/aiboss/trace/aiboss_diag_24035.trc
Instance terminated by PMON, pid = 24025
Wed Aug 02 10:40:19 2017

1.4.2 分析

  • 错误分析 ORA-01595,ORA-00607,ORA-00600错误出现后,10:00:05秒Oracle开启记录此错误的相关信息,随后 Oracle PMON进行由SMON于无法清理资源,无法保证数据一致性而停止实例。 ORA-01595错误提的是数据库smon 进行清理回滚段的extent. 说明undo表空间出现问题。
  • BUG 确认

从宕机前的日志记录来看,数据库遇到的是oracle BUG 12349316. 依据为:

freeing extent (4) of rollback segment (31))                         =====> 与oracle BUG 12349316引发的条件一致,都是在清理extent时引发BUG.
[kdBlkCheckError], [ 3], [ 3], [ 18018]                              =====> 与oracle BUG 12349316 中600错误返回参数一致,都带有18018.
trace 日志(aiboss_smon_24055_i61108.trc)中发现 delete extent 函数    =====> FRAME [ 32] (ktusp_delextent()+76 -> ktsxr_delete())

1.4.3 故障处理

主要的处理思路是先跳过有问题的undo段,然后重建undo表空间

  • 修改参数文件 数据库启动时,查找参数文件的顺序是spfile<ORACLE_SID>.ora –> init<ORACLE_SID>.ora –> init.ora. 因此Oracle 数据库倾向于使用spfile启动数据库。一般环境中也都使用spfile. 如何确认数据库使用的是spfile 还是pfile,使用 " show parameter spfile " 命令即可查看。

    当数据库使用的是spfile参数文件时,由于spfile是 二进制 文件,我们不便于直接修改,因此需要先创建出一个pfile 文本文件。

    create pfile='/tmp/pfile.ora' from spfile;
    此命令的执行不需要启动数据库,进入sqlplus环境即可。
    
     在参数文件中加入以下内容:
    undo_management = MANUAL             # UNDO 段管理方式改为manual
    # 其他可添加内容:
    *.fast_start_parallel_rollback=high  # 以4*cpu 个数开启回滚进程,但是实际上不会真的开始这么多。
    *._allow_resetlogs_corruption = true # 如果数据库需要恢复,且undo与redo不一致,部分redo 无法恢复时需要此参数,允许resetlogs
    
  • 启动数据库

    startup mount pfile='/tmp/pfile.ora';
    alter database open;
    

    如果数据库需要recovery,则执行以下命令:

    recover database until cancel;
    alter database open resetlogs;
    
  • offline存在活动事务的的undo块

    select segment_name,status,tablespace_name
    from dba_rollback_segs
    where status not in ('ONLINE', 'OFFLINE') ;
    
    SEGMENT_NAME                   STATUS           TABLESPACE_NAME
    ------------------------------ ---------------- ------------------------------
    _SYSSMU3_4004931649$           NEEDS RECOVERY   UNDOTBS1
    _SYSSMU4_1126976075$           NEEDS RECOVERY   UNDOTBS1
    _SYSSMU5_4011504098$           NEEDS RECOVERY   UNDOTBS1
    

    将以上内容添加至刚创建的/tmp/pfile.ora中:

    _CORRUPTED_ROLLBACK_SEGMENTS = ('_SYSSMU3_4004931649$','_SYSSMU4_1126976075$','_SYSSMU5_4011504098$')
    

    "_corrupted_rollback_segments" 作用是不使用这几个回滚段。

  • 重启数据库

    startup force pfile='/tmp/pfile.ora';
    
  • 重新创建undo 表空间

    alter tablespace undotbs1 offline ;
    drop tablespace undotbs1 including contents and datafiles;
    create undo tablespace undotbs1 datafile '/data0/aiboss/undotbs1.dbf' size 30G autoextend off;
    alter system set undo_tablespace='UNDOTBS1';
    
  • 重启数据库 重启数据库前,需要修改/tmp/pfile.ora 参数文件,将以下参数去除:

    undo_management=manual
    _allow_resetlogs_corruption=true
    fast_start_parallel_rollback=high
    

    重启:

    startup force pfile='/tmp/pfile.ora';
    create spfile from pfile='/tmp/pfile.ora';
    startup force;
    

1.5 keltnfy-ldmInit

 

1.5.1 [46][1]

hostname 修改后,没有在/etc/hosts 中添加ip 与hostname 的对应关系。

1.6 kkzlpllg:5

该错误是materialized view 中出现的。错误信息如下:

ORA-00600: internal error code, arguments: [kkzlpllg:5], [], [], [], [], [], [], [], [], [], [], []
ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 2809
ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 3025
ORA-06512: at \"SYS.DBMS_SNAPSHOT\", line 2994
  • 原因

    出现这个错误信息,是由于之前删除物化视图与删除表之间的顺序不对。引起的数据字典sys.snap_logdep$中的数据,在进行刷新 或者建立物化视图时,数据出现多行而无法完成完成操作引起的。

    我们删除物化视图和表时,一定要先删除物化视图,再删除物化视图日志,最后再删除表。如果顺序错了,有些信息是不会被删除掉的。

  • 解决

    将sys.snap_logdep$ 中rscn 列是空值的字段设置为非空即可。比如:

      select * from sys.snap_logdep$ where rscn is null;
    
     TABLEOBJ#     SNAPID SNAPTIME        RSCN
    ---------- ---------- --------- ----------
         85590          3 16-NOV-17
         77461          3 16-NOV-17
    
     update sys.snap_logdep$ set rscn=999999 where rscn is null;
    
    2 rows updated.
    
    SQL> commit;
    

Author: HALBERD E-mail: halberd.lee@gmail.com Tel: 18258160531

Created: 2020-05-22 Fri 20:25

Validate

posted @ 2020-05-22 20:26  halberd.lee  阅读(2256)  评论(0编辑  收藏  举报