delayed block cleanout 与 ORA-1555的关系

grassbell

4、有朋友说：ORACLE不会对修改提交后的块做CLEANOUT动作，直到第一次查询该块。
～～
不是不会，是有的时候来不及，比如只会CLEANOUT 10% buffer cache中的buffers等。这10%被clean out 的称为fash clean out；

没有来的则在下一次被重新读入后再作clean out,　这被称为delayed clean out。万一此Transaction Table上的记录被覆盖了（很有可能，因为可能很长时间后才被重新读入），则使用upper bound commit scn 作为其commit scn，这是来自于undo segment中的control scn，上面有讨论。

grassbell

1、TRANSACTION TABLE SLOT 什么时候/条件下会被覆盖？

2、对 hqs4500 说的这段：

这样理解正确否？
TRANSACTION SLOT OVERWRITTEN，所以不知该BLOCK的COMMIT SCN与QUERY SCN孰大孰小，所以无从得到
CONSISTENT IMAGE。对吗?
～～～

1、我推测是具有最小的COMMIT SCN的TRANSACTION SLOT 被重用，这样才符合control scn 的使用原理。可以作个实验。

2、这时query scn 就去比较control scn，上面有讨论。
------------IF query scn<control scn
------------------------则无法知道query scn和commit scn得大小关系，出现ORA-01555错误
------------IF query scn>control scn
------------------------则query scn肯定>commit scn
-------------------------------------则接受该块，进行clean out，并将block 中ITL标记上“U”，表示“upper bound commit” ，并返回1

idler

在我的文章中都已有说明，ZALBB多思考一下，就明白其中的原理了。

licy

这个想法肯定有问题，却突然间冒了出来。
假如一个block刚从datafile中读取出来。
block头中没有xid和相关的scn.
如果查询的时候取scn来对比的话，也是取找不到scn，这和transaction table slot被覆盖发生而无法找到commit scn而发生的区别在哪里？

ZALBB

最初由 licy 发布
[B]这个想法肯定有问题，却突然间冒了出来。
假如一个block刚从datafile中读取出来。
block头中没有xid和相关的scn.
如果查询的时候取scn来对比的话，也是取找不到scn，这和transaction table slot被覆盖发生而无法找到commit scn而发生的区别在哪里？ [/B]

不明白，block头中没有xid和相关的scn.[/COLOR]
没有XID可能还好理解，但不会没有SCN，因为：若该块没被用过，
或者被TRUNCATET过，则不会被读；若被读，则说明该块肯定
被操过，则必定有SCN。

ZALBB

最初由 idler 发布
[B]在我的文章中都已有说明，ZALBB多思考一下，就明白其中的原理了。 [/B]

我发该篇文章的时候，还没看到顶头BITI的回答。

ZALBB

最初由 grassbell 发布
[B]将一致读的步骤细化一点，请指正：


control scn是指事务表中最近一次被重用的transaction slot的前一个事务的commit scn，也就是事务表中所能找到的最小的commit scn了)
[/B]

最近一次被重用的transaction slot，则它的commit scn应该是最大的，怎么是最小的呢？

-----可能我的理解还有问题。

biti_rainy

最初由 ZALBB 发布
[B]

最近一次被重用的transaction slot，则它的commit scn应该是最大的，怎么是最小的呢？

-----可能我的理解还有问题。 [/B]

最近一次被重用的slot 之前的 commit  scn
是 before  image ，不是 current ,也就是比当前还存在的slot的数据小一点的scn

由于这里面涉及到一个 header  rollback 产生 cr  block 的问题，所以我在前文仅仅说了 "control scn 是当前该回滚段中所能获得的最小的一个 commit scn"  .其实一开始我是描述了如何查找 scn 和 rollback 而产生 cr 的，后来想太复杂了可能反而不容易理解，就写了个 所能获得的最小 commit  scn 。 回滚段仅仅记录了scn ,如果需要获得具体数据，就需要 roll back 了

这个你dump 就可以观察出来

我以前做过充分的测试的

licy

假如一个表有3行数据保存于某block中。
A用户更新了第一行，
B用户更新了第二行，
C用户更新了第三行
最后A commit,B rollback, C commit。
这个过程中，如果再有用户连进来，怎么保证读取一致性呢。
单个的block好像是不行的，可是复制多个block在提交或者回滚数据的时候会不会冲突呢，回滚段如何处理呢。

biti_rainy

这个过程中，如果再有用户连进来，怎么保证读取一致性呢。

查询到一个block上的数据的时候，在得到任何数据前，都是先把整个block中所有该回滚的回滚掉（根据query  scn  and  commit  scn 来判断,一直回滚到 commit  scn 小于query  scn），回滚所产生的叫 cr  block ，是一个临时性的buffer，并不和原本的block冲突，多个用户或者多次查询，产生的都是自己的cr block。