[分享]ORA-600 kccpb_sanity_check_2_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 1957 | 回复: 0   主题: [分享]ORA-600 kccpb_sanity_check_2        下一篇 
    本主题由 Administrator 于 2016-8-9 18:28:21 移动
xiaogang.xu
注册用户
等级:上士
经验:251
发帖:13
精华:0
注册:1970-1-1
状态:离线
发送短消息息给xiaogang.xu 加好友    发送短消息息给xiaogang.xu 发消息
发表于: IP:您无权察看 2016-8-9 16:38:26 | [全部帖] [楼主帖] 楼主

 

一、背景

机房搬迁后不久机房断电,导致数据库无法正常启动。

Wed Mar 27 23:40:10 2013

Errors in file /oracle/admin/LANDINGBJ/udump/LANDINGBJ1_ora_901336.trc:

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [2724281], [2724278], [0x000000000], [], [], [], []

ORA-600 signalled during: ALTER DATABASE   MOUNT...

Wed Mar 27 23:40:11 2013

Trace dumping is performing id=[cdmp_20130327234011]

 

二、问题分析与处理 

查询MOS,其解释为:

[kccpb_sanity_check_2] indicates that the seq# of the last read block is higher than the seq# of the control file header block. This is indication of the lost write of the header block during commit of the previous cf transaction. 

kccpb_sanity_check_2 表示最后读取的文件块其 seq# 控制序列号大于控制文件头块的 seq# ,说明在最后执行提交的CF Transaction中,对于头块的写入丢失了。

 

MOS <ORA-00600: [kccpb_sanity_check_2] During Instance Startup> 给出了处理建议

Solution

1) restore a backup of a controlfile and recover

OR

2) recreate the controlfile

OR

3) restore the database from last good backup and recover

 

采用第一种方式恢复,操作如下

NetVault找到最近一次controlfile备份

rman target /

startup nomount 

run {

allocate channel c1 type 'sbt_tape';

restore controlfile from 'c-2490793755-20130327-02';

alter database mount

recover database

alter database open resetlogs 

--由于备份的控制文件采用的RESETLOGS,这里也只能用RESETLOGS,这种方式慎用,如果出现问题,只能reset database to incarnation xx

 

 

三、知识点扩展

checkpoint有关,对恢复会有进一步理解。

什么是rbalrbahrba?

rba就是重做块地址,比如说,用户发出了一条update命令,更新了块A,块A现在变成了脏块,oracle会为他生成一条重做记录。这条重做记录在重做日志文件中的位置就是rba(redo block address)。过了一会儿,假如:A依然还是脏块,此时。用户又发出一条更新块A的命令,这又会生成一条重做记录。第一条更新命令对应的重做记录的rba被称为块Alrba(low rba),第二条更新命令对应的rba,被称为hrba(high rba)。其实,按照lrba来排列,就是按照块首次被修改的顺序来排列。

 

select CPDRT,

       CPLRBA_SEQ || '.' || CPLRBA_BNO || '.' || CPLRBA_BOF "Low RBA",

       CPODR_SEQ || '.' || CPODR_BNO || '.' || CPODR_BOF "On disk RBA",

       CPODS,

       CPODT,

       CPHBT

  from x$kcccp;

 

CPDRT Low RBA   On disk RBA    CPODS   CPODT                         CPHBT

8 223.4.0     223.14.0 3998391  02/11/2013 12:55:37    807131794

说明:

     CPDRT列是检查点队列中的脏块数目。

     CPODS列是on disk rbascn 

     CPODT列是on disk rba的时间戳

     CPHBT列是心跳

 

检查点位置是个rba,他指向着重做日志文件中的某个重做记录。在此位置前的重做记录,其对应的信息已经被写进了数据文件,在此位置后的重做记录,所对应的是数据块,有可能还在内存中。如果发生了实例崩溃,只需要在日志文件中找到检查点位置,从此处开始应用所有的重做日志文件,就完成了前滚操作。实例崩溃后,再次启动数据库,oracle会到控制文件中读取low cache rba,这就是检查点位置。从此处开始应用重做信息,应用到on disk rba处。on disk rba是磁盘中重做日志文件的最后一条重做记录的rba。如果某条命令的重做记录的rba高于on disk rba,那说明此重做记录还没有被写进日志文件中,崩溃发生时,他是不可能被恢复的。on disk rbaoracle前滚操作的终点。on disk 顾名思义 就是'在磁盘上'的意思。比这个更高的rba,都在log buffer中,还没有来的急被写进磁盘中的日志文件。所以是不能被用于恢复的。

 


该贴由system转至本版2016-8-9 18:28:19



赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论