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去回滚。

另外，如果 在数据库打开的过程中process crash导致transaction dead，resource不能被释放的情况，这时候如果另一个进程需要这些resource，那么这个进程将会等待直到pmon清理dead process释放出resource.

如果数据库Crash，重新启动，很久远以前的未提交事务并不在Redo的恢复序列中。

但是未提交事务一定在回滚段事务表上存在，并且State＝10，为活动事务。这就够了。

数据库启动之后，这些事务会被SMON逐个标记为Dead（不可能再活过来了），然后由SMON慢慢去回滚这些事务；也存在另外一种情况，后来的进程会去读这些未提交数据，发现Dead事务未提交，则主动进行回滚。

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中有记录。