love wife & love life —Roger的Oracle&MySQL技术博客

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

非归档恢复的一个模拟例子

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger的Oracle&MySQL技术博客

本文链接地址: 非归档恢复的一个模拟例子

培训班一个学生模拟非归档数据恢复,始终无法打开数据库,我在自己的vm 将其打包的文件进行了恢复,如下是完整的恢复和分析过程,供大家参考!

++++ 编辑pfile并创建相关目录

++++mount启动数据库

+++++ rename datafile & logfile

由于他这里redo有问题,所以只能当redo全丢失来进行处理了。这是为什么rename redo 无法成功的原因。

对于ORA-16433错误,可以通过重建controlfile来解决。

++++++ recreate controlfile

 

++++RECOVER

尝试使用隐含参数,以及屏蔽回滚段,发现错误依旧。对于报错,通常的思路是跟踪,去识别Oracle
为什么会在这个地方报错,下面我们在open resetlogs之前打开10046 event的跟踪:

下面分析10046 trace是重点。通常我们的思路是直接vi 编辑定位到trace的最后,会看到如下的信息:

从10046的跟踪来看,我们发现该SQL访问了如下的几个block:

很明显,前面2个block是system的,后面2个file 3 的block是undo的block。  其中block 208是undo段头block。

我的直观感觉是既然访问这2个block有问题,肯定是有事务,何不直接bbed修改一下呢? 下面进行了尝试:

注意通过看blockdump,我们知道最后一行记录的lock byte为2. 这里我因此进行了修改(实际上这个事务状态是U,是不需要修改的,这一步骤是错误的思路

下面先修改block 321:

下面修改block 225:

修改完成之后,尝试,发现仍然报错,如下:

其中还遇到了让我觉得比较怪异的事情是,如果通过bbed修改undo$.status,强制将回滚段修改offline状态的话,那么会遇到如下的问题

最后再回过头来分析,发现其实犯了一个致命的错误。alert log的ora-01555报错SQL其实和我们10046 最后看到的sql并不是同一个,

换句话讲,直接分析10046 trace的最后部分,是错误的,我们应该找ora-01555报错的这个SQL。

由于10046 trace内容比较多,我们直接切换到最后去查看分析,这样是有问题的。 于是尝试换个思路:

搜索报错的SQLID:3nkd3g3ju5ph1,然后定位到parse ID,然后进行过滤:

大家注意看最后4行,通过过滤我们可以发现其实还有一个file 1 block 20804 也被递归SQL访问了,因此我们之前多次尝试都报错,
是因为直接vi 查看10046 trace的最后部分,没有发现而已,这是非常隐蔽的。

检查发现20804这个block 确实存在一个事务,如下:

修改的同时,我们还需要修改锁定行的lock byte位置,如果找到这一行呢? 很简单,我们通过dump block,然后直接
查看lock:2就行了,定位到是如下的行:

下面我们讲该行的lock type修改为00即可,这样block的校验不再报错。

 

避免ora-016433错误,我再次重建了controlfile,最后顺利打开了该数据库,如下:

虽然是一个测试库,但是恢复过程还是有意思,也发现了自己之前分析10046 trace的一个致命问题,通常是直接vi 查看trace的最后位置去看,这真是致命的,我想这一点,很多人都是这样,希望大家能有所启发!

 

2 Responses to “非归档恢复的一个模拟例子”

  1. wbg Says:

    没太看懂,数据库在什么状况下崩溃,那些东西损坏都不知道

  2. wbg Says:

    身为菜鸟,希望能说的更详细

Leave a Reply

You must be logged in to post a comment.