eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle Database 11g补丁(Patchset)下载地址 | Blog首页 | 深入解析Oracle 的PPT 及 51CTO的颁奖 »

ORA-600 kcbgtcr_13 未解决之问题记录
modb.pro

前几天,遇到一个ORA-00600错误,尝试了很多手段,未能成功启动数据库,记录一下。

这是一个Oracle Database 11g环境,11g之前,类似圣诞遇到的故障,可以较容易的解决,不过在11g中遇到了ORA-600的kcbgtcr_13错误,无法屏蔽一致性读的检验,数据库始终无法Open。

强制resetlogs时报2662错误,再次重启不报2662,但是出现kcbgtcr_13,对11g的研究仍然有限,无法启动这个故障数据库。只有通过其他手段进行恢复。

这个故障中,没有使用BBED,因为出错的块太多,错误信息记录如下,注意出错的块不涉及bootstrap,都是数据文件UNDO块:

Thu Jan 08 16:01:33 2009
SMON: enabling cache recovery
Errors in file e:\diag\rdbms\orcl\orcl\trace\orcl_ora_324.trc (incident=10954):
ORA-00600: 内部错误代码, 参数: [kcbgtcr_13], [], [], [], [], [], [], []
Incident details in: e:\diag\rdbms\orcl\orcl\incident\incdir_10954\orcl_ora_324_i10954.trc
Errors in file e:\diag\rdbms\orcl\orcl\trace\orcl_ora_324.trc:
ORA-00704: 引导程序进程失败
ORA-00600: 内部错误代码, 参数: [kcbgtcr_13], [], [], [], [], [], [], []
Error 704 happened during db open, shutting down database
USER (ospid: 324): terminating the instance due to error 704

不知道大家有没有人遇到过类似的故障,有否处理kcbgtcr_13的经验,请指点一下?


历史上的今天...
    >> 2021-01-12文章:
    >> 2016-01-12文章:
    >> 2012-01-12文章:
    >> 2011-01-12文章:
    >> 2008-01-12文章:
    >> 2006-01-12文章:
           EMC 错了么 之 终结篇
           言论2005
    >> 2005-01-12文章:
           dml lock allocation latch

By eygle on 2009-01-12 17:26 | Comments (13) | Case | 2156 |

13 Comments

隐含参数中还有一个disable system recovery的参数,记不得确切的参数名了,不知道有没有用.

Kindly STARTUP MOUNT the database and run the below mentioned SQL queries and upload the spooled file:

spool recovery_info.txt
set pagesize 20000
set linesize 180
set pause off
set serveroutput on
set feedback on
set echo on
set numformat 999999999999999
alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
select name,controlfile_type,open_mode,checkpoint_change#,ARCHIVE_CHANGE# from v$database;
select incarnation#,resetlogs_change#,resetlogs_time,prior_resetlogs_change#,prior_resetlogs_time,status from v$database_incarnation;
select substr(name, 1, 50), status from v$datafile;
select substr(name,1,40), recover, fuzzy, checkpoint_change# from v$datafile_header;
select GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS,FIRST_CHANGE# from v$log;
select GROUP#,substr(member,1,60) from v$logfile;
select * from v$log_history;
select * from v$recover_file;
SELECT * FROM v$recovery_log;
SELECT f.name,b.status,b.change#,b.time FROM v$backup b,v$datafile f WHERE b.file# = f.file# AND b.status='ACTIVE';
select hxfil FILENUMBER,fhsta STATUS,fhscn SCN,fhrba_Seq SEQUENCE,fhtnm TBS_NAME from x$kcvfh;
spool off
exit

_OFFLINE_ROLLBACK_SEGMENTS 和_CORRUPTED_ROLLBACK_SEGMENTS ,这2个参数搞不定吗

不管用,加了很多Event也不管用,可能我对11g研究的还不透彻

如果没有上面的recovery_info.txt,猜测一下可能在恢复的时候undo表空间的数据文件offline了,可以这样做一下:
执行如下命令:
SQL > startup mount
SQL > alter database datafile 3 online;
SQL > recover database;
SQL > alter database open;
如果有新的报错,请将相关trace文件贴出来。

undo肯定是Online的,否则open的时候根本不可能继续。

cr读也就不会出现了,open出的错误就是上面提到的了,回头我再贴完整一点的出来。

我也没碰到过这个问题,oracle也并未仔细解释这个错误的含义。
但在11g有与此相关的bug。
Bug# 5716869 See Note 5716869.8
OERI[kcbgtcr_13] can occur
Fixed: 11.1.0.6

试试这个补丁,打上后是否能使用隐含参数解决问题!等着你的回应!

Bug# 5716869 在11.1.0.6中已经修正了,我这个版本是11.1.0.6

event="10513 trace name context forever, level 2"
禁止读回滚段呢?
还有就是在抱[2662]的时候,可以设置_minimum_giga_scn试一下

2662 好解决的,能试的event我也加过了,就是不行,春节时又试了一次,仍然没能解决。

看来恐怕只有BBED去慢慢修才能搞定,那就不如DUL来的快了。

我今天也遇到这个问题,是在掉电情况下,环境是HP+soloaris10+oracle11gr2,在databse open时也出现了
Errors in file /export/home/oracle/diag/rdbms/webjob/WEBJOB/trace/WEBJOB_ora_797.trc:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1], [330], [31756], [31771], [], [], [], [], [], [], []
搞了一天也没搞定,不知楼主和各位有没有办法,恳请指点


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com