Android笔记008_关于数据库的前滚和回滚的区别

前滚：

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

回滚：

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

注释：

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

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

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

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

【前滚和回滚交替进行？？--------Recovery在SQL Server启动时也会发生，在数据库启动过程中，SQL Server会检查事务日志，看是否存在已提交或未提交的事务，如果发现在最后一次检查点发生后，还有已提交的事务，则SQL Server会对这些事务进行REDO(ROLL FORWARD)；而如果发现未提交的事务，则进行UNDO（ROLL BACK）。http://blog.csdn.net/hmzhangfeng/article/details/6338021】

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

ps：脏数据的介绍

脏数据是相对于原数据而言的，是指被修改过的，与原数据不一样的数据。

在oracle有SGA中，有个数据高速缓冲区（database buffer cache），由许多大小相等的缓存块组成。这些块根据使用情况不同，可分为脏缓冲块、空闲缓存块和命中缓存块三类：
1. 脏缓存块（dirty buffers）：它保存的是已经被修改过的数据。当一条SQL语句对某个缓存块中的数据进行修改后，这个缓存块就被标记为脏缓存块。
2. 空闲缓存块（free buffers）：不包含任何数据，它们等待后台进程或服务器进程向其中写入数据。当oracle从数据文件中读取数据时，将会寻找空闲缓存块，以便将数据写入其中。
3. 命中缓存块（pinned buffers）：是那些正被使用，或者被显式地声明为保留的缓存块。这些缓存块始终保留在数据高速缓冲区中，不会被换出。