楼主: Alex螺丝钉

oracle实例恢复

[复制链接]
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
11#
发表于 2015-7-23 12:04 | 只看该作者
Alex螺丝钉 发表于 2015-7-23 11:27
还是说在应用重做日志再次插入数据的时候,会恰好在上次插入行的位置操作,以覆盖掉上次的结果?

你可以这样理解

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
12#
发表于 2015-7-23 12:06 | 只看该作者
本帖最后由 zergduan 于 2015-7-23 12:08 编辑

当然(应用全部的redo,这个结论)这只是我的理解;有可能不对,我还没有找到这方面的官方文档

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
13#
发表于 2015-7-23 12:12 | 只看该作者
我来明确你一下你的问题,看看是否我理解的有错误

instance recovery 的起点是数据文件的scn,但是这个scn只有在发生checkpoint的时候才会更改,并且在更改后,dbwr会继续吧脏数据块写到数据文件中(按照lru去写),这样就导致:一个数据文件中的数据块之间不是一致的,某些数据块的scn要大于数据文件的scn。
这个时候如果发生crash,重新打开数据库的时候要开始instance recovery,要应用redo record。并且起点是数据文件的scn。

那么哪些scn大于数据文件scn的块,是否也会被apply redo record?


你要问的问题是不是上面这个?

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
14#
发表于 2015-7-23 12:20 | 只看该作者
我的想法是:
1.如果要避免scn大于数据文件scn的块被应用redo record~
那么每应用一个改变向量,都要先检查改变向量里面的记录和所对应的块中的记录(可能是版本)是否有大于关系,如果有,就应用,如果小于块中的记录就不应用;如果真的这样做,就要消耗更多的时间和资源。
2.如果忽略块的scn,直接应用改变向量,其实就是忽略向量中的初始值,直接将块中的内容改变为这个向量结束的值,这样的做法依然可以完成recovery。而且不用在读取和比对方面消耗时间,仅仅比上面提到的方式多应用了一些改变向量而已。

我们可以看到oracle通过一些参数来控制instance recovery的时间,说明他们认为instance reocvery的时间是可以预估的或者说可以控制的,按照这个理念,应该为第二种方式来应用redo。

当然,仅仅是我的猜测~

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
15#
发表于 2015-7-23 13:41 | 只看该作者
本帖最后由 zergduan 于 2015-7-23 13:42 编辑

刚才测试了一下, 改变向量中只有修改后的值,所以上面说的方法2(忽略块scn,直接应用所有redo record)中,都不存在忽略初始值的概念,因为向量中都不存在初始值,而是直接覆盖修改而已~
Vector content:
col  5: [ 2]  c1 44

使用道具 举报

回复
论坛徽章:
0
16#
 楼主| 发表于 2015-7-23 19:42 | 只看该作者
zergduan 发表于 2015-7-23 12:12
我来明确你一下你的问题,看看是否我理解的有错误

instance recovery 的起点是数据文件的scn,但是这个s ...

谢谢,我问的就是这个意思

使用道具 举报

回复
论坛徽章:
0
17#
 楼主| 发表于 2015-7-23 20:05 | 只看该作者
zergduan 发表于 2015-7-23 13:41
刚才测试了一下, 改变向量中只有修改后的值,所以上面说的方法2(忽略块scn,直接应用所有redo record)中 ...

针对这个我还有点疑问。假如之前对该块上rowid为rowidxxx行的某个字段A进行了更新,然后删除了这一行,后来又插入一条数据并重用了这个rowidxxx,最后又对新插入的数据行某个字段B进行了update,接着又删除了这条记录,最后又插入一行,但是并没有重用前面删除行的rowidxxx,再后来又插入一条数据并重用了rowidxxx。假设这个过程中检查点队列一直没有没有变化,最后这个块又早于检查点队列的第一个块写到磁盘,此时实例崩溃,在启动数据库进行实例恢复的时候,简单的对这个数据块应用redo日志,能保证最后的结果跟实例崩溃时的一致么,(因为崩溃时它已经写到磁盘)也就是说能保证虽然对它应用了重做日志但是最终块上的数据却和实例恢复前磁盘上的数据一致么?
总之就是一句话,因为实例恢复要以磁盘上现有状态为起点,假设某个块在实例崩溃时已经写到磁盘,而且它的重做日志位于lrba和on disk rba之间,该块的所有数据为总称A,那么应用重做日志后,它的数据还应该为A,可以保证这样么?
表述有点儿乱,不知道版主能不能理解我要表达的意思

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
18#
发表于 2015-7-24 08:54 | 只看该作者
--总之就是一句话,因为实例恢复要以磁盘上现有状态为起点,假设某个块在实例崩溃时已经写到磁盘,而且它的重做日志位于lrba和on disk rba之间,该块的所有数据为总称A,那么应用重做日志后,它的数据还应该为A,可以保证这样么?

这句话前面内容的我已经被你绕晕了,就这这句话来说,我们的目的是将所有的block恢复到crash前的状态,redo record中有被改变的块在各各时间点的状态,只需要不停地“覆盖”修改这些块的变化,最终将redo中所有的record应用完,就可以了

使用道具 举报

回复
论坛徽章:
122
现任管理团队成员
日期:2011-05-07 01:45:08
19#
发表于 2015-7-24 08:58 | 只看该作者
重做向量中记录的就是位置,和这个位置当前的(或者说修改后的)值,删除也是修改,这个位置上的没有数据(被删除了),这个位置依然存在,他的重做向量也要存在

使用道具 举报

回复
论坛徽章:
0
20#
 楼主| 发表于 2015-7-24 23:04 | 只看该作者
zergduan 发表于 2015-7-24 08:58
重做向量中记录的就是位置,和这个位置当前的(或者说修改后的)值,删除也是修改,这个位置上的没有数据( ...

谢谢版主!通过在qq群中讨论,然后有人在《临危不惧Oracle11g数据库恢复技术》这本书中找到了这样的一段话。C:\Users\lenovo\Desktop\QQ截图20150724225814C:\Users\lenovo\Desktop\QQ截图20150724225840
貌似可以解释这个问题。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表