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

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

Oracle Crash due to Controlfile sequence# reached 0xffffffff

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

本文链接地址: Oracle Crash due to Controlfile sequence# reached 0xffffffff

近期某客户的一个Oracle数据库的controlfile sequence#居然达到了最大值(42亿 即 0xffffffff);导致数据库直接crash,然后再次启动时发现报错;

 

从上述Oracle alert log来看,Oracle提到了一个文档,查看该文档会发现,Oracle认为该问题是Bug导致,同时也提供了解决方案;其解决方案也不复杂,如下:

 

简单的讲,即先设置event 20324049;然后再重建controlfile,直接open即可;但是在进行重建controlfile时遇到了如下问题:

上述错误提示其实是较为明显的,大概含义是指open数据库时发现有表空间信息丢失。不难看出该数据库在之前应该drop 过一些tablespace。在重建控制文件之后,打开数据库时,表空间的ts#必须是连续的,否则会抛出上述错误。那么怎么解决该问题呢?

我们有个大致的思路,先想办法把丢失的几条记录补充到ts$即可。这里我们通过dbx -a PID来进行操作,设置kokiasg 断点,insert 丢失的5条记录之后,再重启数据库即可。重启之后open数据库发现报ora-00600 [2662];该错误就非常简单了,这里不再多说。oradebug poke 推进scn即可。

最后再重启数据库,去重建一次controlfile,设置event 处理max sequence#的问题;在alert log中会看到如下类似信息:

最后打开数据库即可。至此该case也算是完结了。总的来讲,整个恢复过程不算太复杂。

因为比较少见,我本人也是第一次遇到将controlfile sequence#撑满的情况,比较有趣,所以简单记录一下,跟大家分享!

Leave a Reply

You must be logged in to post a comment.