oracle介质恢复的内部过程--推断与参考
2010-08-13 11:01
211 查看
这个是两年前学习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文件的内容才有此体会。要感谢一些那位“默默无闻”的作者。
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文件的内容才有此体会。要感谢一些那位“默默无闻”的作者。
相关文章推荐
- oracle介质恢复的内部过程--推断与参考
- 详解Oracle介质恢复的内部过程
- 第六章Oracle恢复内部原理(介质恢复)
- 第六章Oracle恢复内部原理(介质恢复)
- 第九章 Oracle恢复内部原理(恢复相关的 V$ 视图)
- oracle 内部错误参考信息
- Oracle 数据库误truncate table恢复过程
- 第四章Oracle恢复内部原理(热备份)
- ORACLE实例恢复过程详细分析--使用dump、BBED等多种工具结合分析
- [置顶] [实验-视频过程]oracle热备份-单个表空间-备份和恢复操作演示
- oracle 的PACKAGE恢复过程
- 重装WINDOWS系统后,恢复ORACLE 10G 全过程记录
- 第四章Oracle恢复内部原理(热备份)
- ORACLE 11G 中采用rman备份异机恢复数据库详细过程
- 重装WINDOWS系统后,恢复ORACLE 10G 全过程记录
- oracle数据文件recover恢复过程
- oracle 闪回功能之--恢复存储过程篇
- Oracle快速创建定时job执行批量转储过程脚本参考案例
- Oracle断电恢复ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [44437], [17323], [18486], [
- 第三章Oracle恢复内部原理(重做日志)