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

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

记一次12TB 测试库的恢复过程

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

本文链接地址: 记一次12TB 测试库的恢复过程

本来是一件很简单的事情,restore文件,然后recover归档,恢复到某个点,然后open resetlogs 打开数据库,但是居然报错,ora-600 [4097],很常见的一个错误,不过比较怪异的是,这里并没有直接提示是哪个回滚段有问题,如下是trace内容:

其实我们可以尝试reset incarnation,然后再去restore归档,然后recover,想想麻烦,反正是测试,所以继续搞下去。

首先利用10046 event 来跟踪一下,发现如下sql报错:

实际上因为oracle 在open的时候会去判断回滚端上是否存在事物,如果存在,那么就会进行update,如果进行update那么也就说明正在open的时候需要更新回滚端的信息。这里尝试使用参数将上述几个回滚端屏蔽掉,发现仍然无法open,再次寻找10046 trace,发现原来是另外一个回滚段可能有问题,如下:

果断再次屏蔽,然后尝试open resetlogs,发热仍然报错,原来这个回滚端用无法直接offline,隐含参数不好用,因此直接bbed 修改状态吧,如下:

修改之后成功open 数据库。

虽然打开了,但是奇葩的还在后面,当我shutdown 再次启动,居然无法启动了。 报错ora-01555,比较经典的错误。

比较郁闷的是system 回滚段。很明显这也跟scn有关系,aix平台,尝试oradebug 修改scn,发现比较费劲。

最后果断bbed 再次修改block(仍然通过10046 trace 寻找相关的block).

最后再次open,发现一切顺利。

由于是测试环境,因此可以随便折腾,生产库,建议不要这样玩,可不好哦~~

One Response to “记一次12TB 测试库的恢复过程”

  1. 世界那么大 Says:

    很不错的博客,第一次来访 支持一下

Leave a Reply

You must be logged in to post a comment.