用户名:  密码:
兄弟在线   

标题:oracle介质恢复的内部过程(推断与参考)

作者:佚名 来源:网络 时间:2011-11-22

这个是两年前学习oracle总结的东西,不算什么新东西,仅作为个人的一个记录,也欢迎大家一起学习讨论。

oracle数据库的介质恢复过程相对非常复杂,oracle毕竟作为一个大系统,设计是相当复杂和庞大的。鄙人结合对controlfile,redo log,datafile等文件的dump内容进行分析,试图深入的了解oracle的介质恢复过程。虽不能从正向了解内部工作机制,但是从逆向推断也能做个大致了解,以此增强对oracle的使用信心吧。

从这里开始吧:

1,获取media-recovery-start SCN.
检查所有数据文件头,选择最小的checkpoint SCN值作为start SCN。

假如获取到的checkpoint SCN值在数据文件的offline的SCN范围内,则采用offline-end的SCN。

2,checkpoint structure检查thread启动数量
media-recovery SCN中的checkpoint structure检查在该SCN点有几个thread线程启动了。

3,分配log buffer
为第二步中的每个启动的thread分配log buffer。

4,打开log文件
  --如果log文件在线,系统将会自动打开;
  --如果已经归档,将会提示管理员输入log文件名称。

5,分配独占型media recovery lock
为每个需要执行media recovery的数据文件分配一个excusive(独占)media recovery lock。

6,对每个数据文件设置fuzzy bit

7,checkpoint bitvec 决定了初始启动的thread。

8,thread线程读取相应的redo,并应用于数据库。

9,Media recovery发生检查点:
     --应用redo文件过程中,需要转换redo文件,每当转换时都会发生Media Recovery checkpoints。
     --当数据文件的STOP SCN达到时,也会发生Media Recovery checkpoints,数据文件头的checkpoint也会被推进到该值。

10,完成media checkpoint
所有的thread完成其对应的redo日志应用,达到数据文件的有限STOP SCN值,完成了media recovery;
media recovery fuzzy bit被清除,或者叫做重置为(0x0000.00000000 day/month/year hh24:mi:ss);
接着更新数据文件头和控制文件,表明了数据库整体一致。

 

文档参考:记着开始时从google找到一篇介绍oracle internal的文章作为了参考,并结合着dump文件的内容才有此体会。要感谢一些那位“默默无闻”的作者。



编辑:admin 总点击 [1281]   评论  0 查看评论
上一篇:oracle 11g 自动内存的管理
下一篇:解决oracle用户连接失败的方法
【关闭窗口】
您可能感兴趣的文章
我要评论
          
评论标题:   可以输入250
 
验证数字: 3 + 4 =
兄弟友情提示
· 请自觉遵守国家有关法律、法规,尊重网上道德。
· 兄弟在线坚决抵制不良言行,违者文责自负。
· 如果文章有版权或其他问题等,请联系我们,我们会尽快处理。
· 文章注名来自网络的旨在传播共享信息,不做其它用途;注名原创的本站支持原创,但不代表同意其观点。
· 兄弟在线拥有管理用户与其文章和评论的一切权利,并有权在网站内转载或引用。
兄弟在线
兄弟热门文章
兄弟推荐文章
兄弟站内搜索

兄弟感兴趣的文章
兄弟最新影视