关于实例恢复or崩溃恢复过程中roll-forward和roll-back的一些细节的思考

我们知道在做instance-recovery或者crash-recovery的时候，大致有这么几步：

第一步，Roll-forward即前滚，将redo-log-online中的数据应用到datafile中，这一步结束之后，database事实上已经打开，普通用户已经可以登录数据库做操作；紧接着要做roll-back，这一步做的操作其实是对第一步中一些错误的弥补，因为第一步中redo-online中的数据并不全都是committed，为什么？回顾一下什么样的数据会被写入到redo-log—online，也就是redo-log-buffer的触发条件：

1.redo-log-buffer达到1M的时候；

2.redo-log-buffer达到三分之一满的时候；

3.每三秒会触发redo-log-buffer的写操作；

4.用户 commit；

5.database发生checkpoint的时候；

以上五个条件都会促使redo-log-buffer进程将redo-buffer中的数据写入到redo-log-online。那么这个时候就很清楚了，我可以用commitedt和uncommitted将redo-log-online中的内容一刀切成2部分，由于第一阶段的roll-forward将redo-log-online中所有的数据都应用到datafile中了，其中就包含uncommitted的数据，但是oracle的机制是未提交的数据不写入datafile中，因此在恢复的过程中有了第二步，即roll-back，将已经应用到darafile中的uncommitted的数据，根据undosegents中内容做回滚，保证数据一致性，使得database回到崩溃发生前的一个一致性的时点上去。

另 instance-recovery或者crash-recovery的恢复操作是由oracle的内部进程Smon来自动执行的，不需要DBA干预，用户要做的就是waiting in-patient and have a cup of tea.。用句官方的话叫数据库的实例恢复或者崩溃恢复对于普通用户来说是透明的。