Android笔记008_关于数据库的前滚和回滚的区别
2014-11-23 09:25
148 查看
[b]前滚:[/b]
未完全提交的事务,即该事务已经被执行commit命令了,只是现在该事务修改所对应的脏数据块中只有一部分被写到磁盘上的数据文件中,还有一部分已经被置为提交标记的脏块还在内存上,如果此时数据库实例崩溃了,则当数据库实例恢复时,就需要用前滚(这个机制)来完成事务的完全提交,即将先前那部分已经被置为提交标记且还在内存上的脏块写入到磁盘上的数据文件中。
[b]回滚:[/b]
未提交的事务,即该事务未被执行commit命令。但是此时,该事务修改的脏块中也有可能一部分脏块写入到数据文件中了。如果此时数据库实例崩溃了,则当数据库实例恢复时,就需要用回滚(这个机制)来将先前那部分已经写入到数据文件的脏块从数据文件上撤销掉。
注释:
实例恢复,就是oracle软件系统根据数据库实例崩溃前最后一次检查点的那一刻到数据库实例崩溃那一刻期间所做的所有操作(无论该操作是否有提交的,这些操作可以从重做日志上读取)对该数据库实例对应的数据库(特别是数据文件部分做恢复,当然其他配合数据文件的文件,如控制文件,日志文件,也会做相关的恢复修改)进行前滚,即将该期间的操作重做一遍。之后再将其中未提交的操作进行回滚。这里,可能就有人疑问了,为什么前滚时不只做提交的操作,未提交的操作就不要做就好了嘛?因为数据库实例崩溃前,未被执行commit命令的事务,其所修改的脏块中也有可能一部分脏块已经写入到数据文件中了,所以需要进行回滚操作。
总之,实例恢复时,先做前滚,后做回滚。
(疑问)至于为什么不用如下方法就不得而知了?
该方法具体为,前滚时只做提交的操作,不做未提交的操作,到回滚操作阶段时,再去回滚那些(记录在重做日志里的)未提交的操作。
【前滚和回滚交替进行??--------Recovery在SQL Server启动时也会发生,在数据库启动过程中,SQL Server会检查事务日志,看是否存在已提交或未提交的事务,如果发现在最后一次检查点发生后,还有已提交的事务,则SQL Server会对这些事务进行REDO(ROLL FORWARD);而如果发现未提交的事务,则进行UNDO(ROLL
BACK)。http://blog.csdn.net/hmzhangfeng/article/details/6338021】
注意: [b] 未提交的事务 提交的事务 未完全提交的事务 完全提交的事务[/b]
ps:脏数据的介绍
未完全提交的事务,即该事务已经被执行commit命令了,只是现在该事务修改所对应的脏数据块中只有一部分被写到磁盘上的数据文件中,还有一部分已经被置为提交标记的脏块还在内存上,如果此时数据库实例崩溃了,则当数据库实例恢复时,就需要用前滚(这个机制)来完成事务的完全提交,即将先前那部分已经被置为提交标记且还在内存上的脏块写入到磁盘上的数据文件中。
[b]回滚:[/b]
未提交的事务,即该事务未被执行commit命令。但是此时,该事务修改的脏块中也有可能一部分脏块写入到数据文件中了。如果此时数据库实例崩溃了,则当数据库实例恢复时,就需要用回滚(这个机制)来将先前那部分已经写入到数据文件的脏块从数据文件上撤销掉。
注释:
实例恢复,就是oracle软件系统根据数据库实例崩溃前最后一次检查点的那一刻到数据库实例崩溃那一刻期间所做的所有操作(无论该操作是否有提交的,这些操作可以从重做日志上读取)对该数据库实例对应的数据库(特别是数据文件部分做恢复,当然其他配合数据文件的文件,如控制文件,日志文件,也会做相关的恢复修改)进行前滚,即将该期间的操作重做一遍。之后再将其中未提交的操作进行回滚。这里,可能就有人疑问了,为什么前滚时不只做提交的操作,未提交的操作就不要做就好了嘛?因为数据库实例崩溃前,未被执行commit命令的事务,其所修改的脏块中也有可能一部分脏块已经写入到数据文件中了,所以需要进行回滚操作。
总之,实例恢复时,先做前滚,后做回滚。
(疑问)至于为什么不用如下方法就不得而知了?
该方法具体为,前滚时只做提交的操作,不做未提交的操作,到回滚操作阶段时,再去回滚那些(记录在重做日志里的)未提交的操作。
【前滚和回滚交替进行??--------Recovery在SQL Server启动时也会发生,在数据库启动过程中,SQL Server会检查事务日志,看是否存在已提交或未提交的事务,如果发现在最后一次检查点发生后,还有已提交的事务,则SQL Server会对这些事务进行REDO(ROLL FORWARD);而如果发现未提交的事务,则进行UNDO(ROLL
BACK)。http://blog.csdn.net/hmzhangfeng/article/details/6338021】
注意: [b] 未提交的事务 提交的事务 未完全提交的事务 完全提交的事务[/b]
ps:脏数据的介绍
脏数据是相对于原数据而言的,是指被修改过的,与原数据不一样的数据。 在oracle有SGA中,有个数据高速缓冲区(database buffer cache),由许多大小相等的缓存块组成。这些块根据使用情况不同,可分为脏缓冲块、空闲缓存块和命中缓存块三类: 1. 脏缓存块(dirty buffers):它保存的是已经被修改过的数据。当一条SQL语句对某个缓存块中的数据进行修改后,这个缓存块就被标记为脏缓存块。 2. 空闲缓存块(free buffers):不包含任何数据,它们等待后台进程或服务器进程向其中写入数据。当oracle从数据文件中读取数据时,将会寻找空闲缓存块,以便将数据写入其中。 3. 命中缓存块(pinned buffers):是那些正被使用,或者被显式地声明为保留的缓存块。这些缓存块始终保留在数据高速缓冲区中,不会被换出。
相关文章推荐
- sql2000 关于ExecuteNonQuery与ExecuteScalar区别的探讨,返回数据库数据的行数通常用intCount=(int)cmd.ExecuteScalar()
- 关于数据库SQL优化的一些笔记
- 关于Android中保存activity的状态的几点学习笔记
- Android下SQLite3数据库操作笔记(二)之-SQLiteOpenHelper
- 【转】【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- JDBC之关于数据库操作回滚研究(JDBC之四)
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- 【学习笔记】关于Android的Surface系统
- [android]第一篇blog 关于android中加入外界的db文件进行数据库访问
- Android笔记:invalidate()和postInvalidate() 的区别及使用
- android数据库文件路径问题笔记
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- android 数据库 SQLiteOpenHelper和ContentProvider学习笔记---添加修改删除数据之联系人(二)
- 关于开源项目android--Imagedownloader的学习笔记
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的优化笔记!
- 关于数据库中使用 left join on ...and ...和 left join on ....where ...区别,和使用group by 要注意的情况
- android 数据库 SQLiteOpenHelper和ContentProvider学习笔记---添加数据及显示(一)
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- 关于开源项目android--Imagedownloader的学习笔记
- Android 关于 如何使用外界导入的数据库文件