关于INSTANCE RECOVERY过程的理解

显示全部楼层 · 2014-2-19 11:55:14

关于INSTANCE RECOVERY你要是想说的简单可以把它描述的十分简单就是REDO+UNDO
可是具体ORACLE是如何实现的就不清楚了下面是几个人对于这个过程的描述
wanghai－－－
1. 增量检查点
在checkpoint queue的基础上实现了增量检查点，每3秒发生一次checkpoint heartbeat，记录dbwr上次写成功的最大RBA(redo block address)。这样的话做instance recovery的时候就从这个rba开始，而不是从上次checkpoint scn开始，大大节省了恢复时间。
2. twice scan of redo log
在应用redo之前，redo将会被操作两次，第一次去扫描哪些redo record需要被应用，因为9i在redo里添加了dbwr写数据块的信息，所以dbwr发生前的日志将不会被应用。第二步就是选出需要被应用的日志然后开始rollforward。
3. rollforward
在做instance recovery时必须先定位到redo log 然后应用所有日志到datafile，这时候包括了committed和uncommitted的数据。当做完rollward，数据库就可以open了。
4. rollback
因为rollforward产生了uncommitted数据，所以必须回滚这些数据。这将由smon和on-demand rollback来实现。smon将会扫描undo segment header去标志所有活动事务为dead，然后会逐渐去回滚这些事务。另外on-demand rollback提供了前台进程进行rollback，当前台进程企图获得被dead事务占用row lock，这时候前台进程将会去undo segment取得before image去回滚这个块，至于其他被这个dead事务lock的块就等待smon去回滚。
kamus－－－
1. 一个数据块发生更新，必然写回滚
2. 回滚段的block变化也记录在redo中
一份未提交的数据必定在回滚中有相应的前镜像，任何正常的恢复都一定会把这些变化重新构建出来。

想像一下
1. update事务1更新了block 1
2. 回滚段1记录了block1的前镜像
3. checkpoint
4. update事务2更新了block2
5. 回滚段2记录了block2的前镜像
6. instance crash
现在重启数据库
1. 根据redo重新构建block2
2. 根据redo重新构建回滚段2
3. database open
4. SMON用回滚段2的数据回滚block2，SMON用回滚段1的数据回滚block1
最后一步也可能是
在另外一个select检索到block1或者block2的时候，发现这两个block的数据都是未提交的，此时再回滚block1和block2。
所以，只要有相应的回滚数据存在，无论什么时候oracle都可以找到一致的数据，oracle只需要知道这个事务是提交了的还是没提交了的，而这点在block header ITL中有记录。
详细的recovery过程可以下载文档 http://www.inthirties.com/thread-83-1-1.html

千问 · 2014-2-19 11:55:14

学习学习。。。。

千问 · 2014-2-19 11:55:14

温习一下。。

千问 · 2014-2-19 11:55:14

顶起来

千问 · 2014-2-19 11:55:14

"在另外一个select检索到block1或者block2的时候，发现这两个block的数据都是未提交的，此时再回滚block1和block2。 "
如果回滚数据的回滚段（undo）被覆盖,怎么来回滚block1，block2，是从redo或者archive log中再来构造undo吗？

千问 · 2014-2-19 11:55:14

>>根据redo重新构建回滚段2
未提交的undo是不会被覆盖的，回滚段里还有block2的前镜像，为什么需要重建？