前滚：

        未完全提交的事务，即该事务已经被执行commit命令了，只是现在该事务修改所对应的脏数据块中只有一部分被写到磁盘上的数据文件中，还有一部分已经被置为提交标记的脏块还在内存上，如果此时数据库实例崩溃了，则当数据库实例恢复时，就需要用前滚（这个机制）来完成事务的完全提交，即将先前那部分已经被置为提交标记且还在内存上的脏块写入到磁盘上的数据文件中。

回滚：

       未提交的事务，即该事务未被执行commit命令。但是此时，该事务修改的脏块中也有可能一部分脏块写入到数据文件中了。如果此时数据库实例崩溃了，则当数据库实例恢复时，就需要用回滚（这个机制）来将先前那部分已经写入到数据文件的脏块从数据文件上撤销掉。


注释：

实例恢复，就是oracle软件系统根据数据库实例崩溃前最后一次检查点的那一刻到数据库实例崩溃那一刻期间所做的所有操作（无论该操作是否有提交的，这些操作可以从重做日志上读取）对该数据库实例对应的数据库（特别是数据文件部分做恢复，当然其他配合数据文件的文件，如控制文件，日志文件，也会做相关的恢复修改）进行前滚，即将该期间的操作重做一遍。之后再将其中未提交的操作进行回滚。这里，可能就有人疑问了，为什么前滚时不只做提交的操作，未提交的操作就不要做就好了嘛？因为数据库实例崩溃前，未被执行commit命令的事务，其所修改的脏块中也有可能一部分脏块已经写入到数据文件中了，所以需要进行回滚操作。

   总之，实例恢复时，先做前滚，后做回滚。

(疑问)至于为什么不用如下方法就不得而知了？

   该方法具体为,前滚时只做提交的操作，不做未提交的操作，到回滚操作阶段时，再去回滚那些（记录在重做日志里的）未提交的操作。


注意：  未提交的事务     提交的事务   未完全提交的事务  完全提交的事务