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

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

用event 10013验证实例恢复的终点?

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

本文链接地址: 用event 10013验证实例恢复的终点?

这个测试源于微博上一个哥们的一个问题,如下图:
用event 10013验证实例恢复的终点?插图

这里一个,删除了3条数据。上面这里做delete操作之前之所以切换redo 是因为dump信息太多了,查看不方便,
这里我切换以后,删除几条记录,就dump,那么logfile的dump内容就很少了,非常的直观。

—–log file dump

此时current redo logfile的3条redo 记录:

REDO RECORD – Thread:1 RBA: 0x000025.00000002.0010 SCN: 0x0000.0044821b –> 4489755

REDO RECORD – Thread:1 RBA: 0x000025.00000003.0010 SCN: 0x0000.0044821f –> 4489759

REDO RECORD – Thread:1 RBA: 0x000025.00000004.0010 SCN: 0x0000.00448222 –> 4489762

最后一条记录是RBA: 0x000025.00000004.0010 转换为10进制为logseq 37,block 4,对应scn为4489762。

另外,dump下controlfile :

提取检查点信息即可:

THREAD #1 对于redo 组1
dirty:41 说明有41个redo block需要scan
—low cache rba 地址:(0x24.4.0) 转换为10进制为36.4
—on disk rba地址:(0x25.5.0) 转换为10进制为37.5
—on disk scn : 0x0000.00448223 转换为10进制为 4489763

——设置event 10013 跟instance recovery

此时的alert log信息如下:

event 10013 的trace信息如下:

我们可以清楚的看到,这里low rba明显要比thread checkpoint大,从最后一行的
start recovery at logseq 可以看出,实例恢复的起点是low cache rba。

从前面的alert log我们可以清楚的看到,恢复的终点地址是:4509763,很明显
这个scn要大于on disk scn 4489763。

所以实例恢复的终点不是on disk rba。

有一点比较奇怪的是,current logfile的最后一条记录scn为4489762,最后一条记录为logseq 37,block 4.

不知道这个block 5是怎么出来,难得哪个地方不对 ?这里有可能信息还没来得及写入到logfile,
我就shutdown abort了,这里进行实例恢复可能还利用了undo,看来这个问题还需要进一步探讨。

备注:最后看微博,发现dbsnake已经写了一篇比较详细的文章:Oracle里Instance Recovery的终点

One Response to “用event 10013验证实例恢复的终点?”

  1. Dong_2 Says:

Leave a Reply

You must be logged in to post a comment.