有关延迟块儿清除、快照过旧、读一致的总结
2014-12-16 14:46
141 查看
有关延迟块儿清除、快照过旧、读一致的总结,希望把这三个知识点串联一起做个总结,没有巨细无遗的写完每个地方,欢迎大家一起讨论,如果有前辈指出错误的地方更是不胜感激。
Blockcleanout 并不是指把脏块儿写入磁盘,只是单纯的指把DB buffer中一个块从 dirty 变为 clean,表明这个块里面的数据是干净的、最新的,本质上是更新 block header 中的一个标志位——ITL(Interested Transaction List)和block
SCN。
什么是delayed block cleanout?
每当事务commit 时,事务修改过的块儿就会被 cleanout,不过Clean out有2种方式:fast commit cleanout和delayed blockcleanout。
1.fastcommit cleanout 算是真正意义上的 cleanout,当做fast commit cleanout时,Oracle将事务commit
时的系统scn作为commitSCN,马上更新block上 ITL 、block scn 和 undo segment header的Transaction table的slot(槽)上的 scn,三者是一致的。
2.delayedblock cleanout 是将 cleanout 操作延后了,由于某些原因只是用commit SCN更新了undo segment header 的 Transaction table 上的slot scn,而并未做block上的更新,等待下次使用此block的时候,再用undo
segment header 的 Transaction table 上的slot scn(与之前事务的commit SCN相同)去更新 block scn 和 ITL。(当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时需要在读入后完成块清除)
为什么要执行delayed block cleanout呢?
这是出于性能考虑的,我们首先来看哪些块会做delayed block cleanout
前提:Oracle有一个modifiedblock list 结构(checkpoint queue机制?),用来记录每个transaction更改过的block,每个transaction可以在这个list上面记录大约10%buffercache这多的modified
block。
事务commit 时:
更改过的block低于10%,则oracle可以根据modified
block list定位到那些块并做fast commit cleanout。
更改过的block超过10%,则超出部分就做delayed
block cleanout。
未commit前,由于事务耗时太长已经被写至磁盘的块做delayed block cleanout。
这里就可以看出,不立即cleanout 的原因有二,但本质都是不能立刻在DB
4000
buffer中找到对应的块儿,前者是超出10%,没有在list中记录,后者是已经写入磁盘,如果再重新读回DB buffer再修改,IO太多,都影响性能。
和快照过旧是什么关系?
前提:别的会话用过这个块儿(clean),或者正在占用这个块儿(dirty),都会在块儿上记录ITL(itl、xid、flag、uda、scn\fsc)。
1.当发出一条select语句时,ORACLE会记录下这个时刻SCN,然后在buffer cache中查找需要的BLOCK,或者从磁盘上读。
2.首先要查看最近一个修改这个块的事务的flag,如果需要cleanout 就马上执行。如果执行成功或者不需要执行就接着比较ITLSCN和select SCN,如果ITL SCN > select SCN,证明块儿的版本是比要select的新,要执行读一致找旧版本。
3.ORACLE就会根据ITL中的uba找到UNDO信息获得该block的前镜像,然后在buffercache 中构造出CR块,此时ORALCE也会检查构造出来的CR块儿中ITL记录的SCN,如果SCN还大于select时刻的SCN,那么一直重复构造前镜像,直到找到需要的块儿,这样ORACLE就实现了多版本。但如果在构造前镜像的过程中所需的UNDO信息被覆盖了,就会报快照过旧的错误。所以简单来说,是利用递推方式去找到和自己select同一SCN的那个块儿的版本,如果找不到就是快照过旧。
而对于延迟清除的块儿,尽管对应的事务已经commit,但自己本身还是dirty状态。之前commit的时候只是更新undo segment header的Transaction table的slot(槽)上的 scn,而块儿自己的itl 和 block scn却没有更新。当再次访问到这个块儿的时候,肯定要完成剩余的工作,即上面第二步说的马上cleanout——更新这个块儿的itl scn
和 blockscn。之前说过,如果clean执行成功就接着比较ITL SCN和selectSCN来决定是否需要要执行读一致。但如果因为undo被覆盖,就获得不了commit SCN,连cleanout也不能执行,也就比较不了大小了。报错还是快照过旧。
Blockcleanout 并不是指把脏块儿写入磁盘,只是单纯的指把DB buffer中一个块从 dirty 变为 clean,表明这个块里面的数据是干净的、最新的,本质上是更新 block header 中的一个标志位——ITL(Interested Transaction List)和block
SCN。
什么是delayed block cleanout?
每当事务commit 时,事务修改过的块儿就会被 cleanout,不过Clean out有2种方式:fast commit cleanout和delayed blockcleanout。
1.fastcommit cleanout 算是真正意义上的 cleanout,当做fast commit cleanout时,Oracle将事务commit
时的系统scn作为commitSCN,马上更新block上 ITL 、block scn 和 undo segment header的Transaction table的slot(槽)上的 scn,三者是一致的。
2.delayedblock cleanout 是将 cleanout 操作延后了,由于某些原因只是用commit SCN更新了undo segment header 的 Transaction table 上的slot scn,而并未做block上的更新,等待下次使用此block的时候,再用undo
segment header 的 Transaction table 上的slot scn(与之前事务的commit SCN相同)去更新 block scn 和 ITL。(当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时需要在读入后完成块清除)
为什么要执行delayed block cleanout呢?
这是出于性能考虑的,我们首先来看哪些块会做delayed block cleanout
前提:Oracle有一个modifiedblock list 结构(checkpoint queue机制?),用来记录每个transaction更改过的block,每个transaction可以在这个list上面记录大约10%buffercache这多的modified
block。
事务commit 时:
更改过的block低于10%,则oracle可以根据modified
block list定位到那些块并做fast commit cleanout。
更改过的block超过10%,则超出部分就做delayed
block cleanout。
未commit前,由于事务耗时太长已经被写至磁盘的块做delayed block cleanout。
这里就可以看出,不立即cleanout 的原因有二,但本质都是不能立刻在DB
4000
buffer中找到对应的块儿,前者是超出10%,没有在list中记录,后者是已经写入磁盘,如果再重新读回DB buffer再修改,IO太多,都影响性能。
和快照过旧是什么关系?
前提:别的会话用过这个块儿(clean),或者正在占用这个块儿(dirty),都会在块儿上记录ITL(itl、xid、flag、uda、scn\fsc)。
1.当发出一条select语句时,ORACLE会记录下这个时刻SCN,然后在buffer cache中查找需要的BLOCK,或者从磁盘上读。
2.首先要查看最近一个修改这个块的事务的flag,如果需要cleanout 就马上执行。如果执行成功或者不需要执行就接着比较ITLSCN和select SCN,如果ITL SCN > select SCN,证明块儿的版本是比要select的新,要执行读一致找旧版本。
3.ORACLE就会根据ITL中的uba找到UNDO信息获得该block的前镜像,然后在buffercache 中构造出CR块,此时ORALCE也会检查构造出来的CR块儿中ITL记录的SCN,如果SCN还大于select时刻的SCN,那么一直重复构造前镜像,直到找到需要的块儿,这样ORACLE就实现了多版本。但如果在构造前镜像的过程中所需的UNDO信息被覆盖了,就会报快照过旧的错误。所以简单来说,是利用递推方式去找到和自己select同一SCN的那个块儿的版本,如果找不到就是快照过旧。
而对于延迟清除的块儿,尽管对应的事务已经commit,但自己本身还是dirty状态。之前commit的时候只是更新undo segment header的Transaction table的slot(槽)上的 scn,而块儿自己的itl 和 block scn却没有更新。当再次访问到这个块儿的时候,肯定要完成剩余的工作,即上面第二步说的马上cleanout——更新这个块儿的itl scn
和 blockscn。之前说过,如果clean执行成功就接着比较ITL SCN和selectSCN来决定是否需要要执行读一致。但如果因为undo被覆盖,就获得不了commit SCN,连cleanout也不能执行,也就比较不了大小了。报错还是快照过旧。
相关文章推荐
- 有关浮动和常用清除方法总结
- 有关浮动和常用清除方法总结
- 几点有关Web Services的技术学习总结
- 对论坛中有关数据类型转换的总结
- 有关TinyXML使用的简单总结
- MySQL字符集不一致的解决办法总结
- 有关UNICODE、ANSI字符集和相关字符串操作的总结!
- 有关datagrid的若干总结
- [转]有关UNICODE、ANSI字符集和相关字符串操作的总结!
- 有关TinyXML使用的简单总结
- 有关UNICODE、ANSI字符集和相关字符串操作的总结!
- 0831【总结】有关在eclipse、lomboz和jboss下的J2EE-EJB
- 有关c的一些总结
- 有关 sizeof和strlen的总结[原创,总结]
- 有关UNICODE、ANSI字符集和相关字符串操作的总结
- 对论坛中有关数据类型转换的总结
- 有关数据类型转换的总结
- 有关C语言指针学习思想的随笔常用形式的总结(原创)
- 《第四章 初始化和清除》总结
- 有关TinyXML使用的简单总结