love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

ora-00600 kccpb_sanity_check_2和kclchkblk_4的恢复case

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: ora-00600 kccpb_sanity_check_2和kclchkblk_4的恢复case

前几天某客户的数据库出现异常,导致无法正常打开。实际上客户联系我们之前,他们已经联系过其他厂家进程了多次恢复。

从alert log 我们看到了几个常见的错误:

对于第一个ora-00600 [kccpb_sanity_check_2] ,很明显是跟控制文件有关,关于这一点,Oracle mos文档有相关记录,如下:

Ora-00600: [Kccpb_sanity_check_2], [3621501],[3621462] On Startup [ID 435436.1]

该文档提到了该错误的原因如下:

[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.

针对该错误的解决方案很简单,如下:

查看日志我们发现还存在另外一个错误ora-00600 [kclchkblk_4],很明显这个是跟数据块有关系的。最后我们发现也确实存在坏块。

其中我们通过隐含参数强制把库打开了,还用了event 10015等手段,甚至使用了*._minimum_giga_scn 参数。

当数据库打开之后,虽然还有一系列的报错,但是处理都相对简单了,这里不再累述。
该数据库不到100G,但是客户却没有完整的备份,貌似还是非归档,这确实不应该啊。

Leave a Reply

You must be logged in to post a comment.