consistent read（读一致性）的通俗理解

biti_rainy

最初由 solearn 发布
[B][QUOTE]最初由 samchj 发布
[B]首先介绍undo 中的简单结构：
undo header-->transaction table-->undo entries（undo block）-->
undo entries包含的只有一个行改变的col值的undo，并不包含整个行的befor image。
KDO undo record:
KTB Redo op: 0x02 ver: 0x01 op: C uba: 0x02000004.0005.0a
KDO Op code: URP xtype: XA bdba: 0x01c00007 hdba: 0x01c00006
itli: 1 ispac: 0 maxfr: 4863 tabn: 0 slot: 1(0x1) flag: 0x2c
lock: 0 ckix: 0 ncol: 8 nnew: 2 size: -1
col 5: [ 3] c2 20 24
col 7: [ 2] c1 1f


consistent read:
1.读取数据块，如果该块在内存中，则增加一个克隆用于undo
2.读取行头：
tab 0, row 0, @0x1e4c
tl: 44 fb: --H-FL-- lb: 0x1 cc: 8
3.检查lb是否这里有一个itl：
Itl  Xid                      Uba                     Flag
0x01 xid: 0x0003.000.00000010 uba: 0x02000004.0005.09 ----
4.如果有，则读取这个itl的xid，xid=us#.slot#.wrap#

-------------------------------------------------------------------------------------------------------------

看到这里，由一个疑问：
检查lb如果为0，会怎样呢？
如果lock byte为零，意味着这个块被cleanout过。那么这个行上执行的前一个事务（已经提交）的System commit number还是有可能大于查询的snapshot scn。oracle 能够在这里直接读这个块吗？ [/B]

只要 ITL 上的 cmimit  scn(or  upper bound scn) 大于查询scn，则就会继续roll ，一直到满足条件或者  回滚段中找不到而出1555为止。

solearn

最初由 biti_rainy 发布
[B]

只要 ITL 上的 cmimit  scn(or  upper bound scn) 大于查询scn，则就会继续roll ，一直到满足条件或者  回滚段中找不到而出1555为止。 [/B]

如果在第3步，row header中的lock byte的值为0，还能找到对应的ITL吗? 还是说即使这一行找不到对应的ITL，也要在block header里查看ITL?

jametong

最初由 solearn 发布
[B]

如果在第3步，row header中的lock byte的值为0，还能找到对应的ITL吗? 还是说即使这一行找不到对应的ITL，也要在block header里查看ITL? [/B]

是的, 我记得block header中有历史的itl的一个list, 上限是255, 如果由于事务过多导致在block header中也找不到对应的itl信息, 导致这条sql无法实现Consistent Read的话, 同样会报ora-1555的错误.

biti_rainy

最初由 solearn 发布
[B]

如果在第3步，row header中的lock byte的值为0，还能找到对应的ITL吗? 还是说即使这一行找不到对应的ITL，也要在block header里查看ITL? [/B]

你把 顺序给搞反了：

首先，block  roll 并不是因为 读到某行数据而去 决定是否要roll。

当进程读到一个block当还没有去 read row 的时候，首先就会检查所有的itl ，一直roll 到 所有itl 都满足 查询条件为止。  根本不关心 lock  byte是多少。 直到所有itl 显示 block 满足查询条件的时候才去访问 row 数据。一旦去读row 数据，就根本不再关心 lock byte 或者itl 了。

lock  byte是给 dml 用的，不是给查询用的。

biti_rainy

最初由 jametong 发布
[B]

是的, 我记得block header中有历史的itl的一个list, 上限是255, 如果由于事务过多导致在block header中也找不到对应的itl信息, 导致这条sql无法实现Consistent Read的话, 同样会报ora-1555的错误. [/B]

block  header 中有历史的itl 的list 是什么意思？

solearn

最初由 jametong 发布
[B]

是的, 我记得block header中有历史的itl的一个list, 上限是255, 如果由于事务过多导致在block header中也找不到对应的itl信息, 导致这条sql无法实现Consistent Read的话, 同样会报ora-1555的错误. [/B]

如果lock byte的值为0X01，那么这行对应itl 0X01。如果lb为0，它怎么知道在历史的itl list中那一个slot是对应它的？

biti_rainy

最初由 solearn 发布
[B]

如果lock byte的值为0X01，那么这行对应itl 0X01。如果lb为0，它怎么知道在历史的itl list中那一个slot是对应它的？ [/B]

lock  byte 是给  dml用的，为0  表示 事务已经结束了。  dml 不需要去 roll 到某个时间点。

solearn

最初由 biti_rainy 发布
[B]

你把 顺序给搞反了：

首先，block  roll 并不是因为 读到某行数据而去 决定是否要roll。

当进程读到一个block当还没有去 read row 的时候，首先就会检查所有的itl ，一直roll 到 所有itl 都满足 查询条件为止。  根本不关心 lock  byte是多少。 直到所有itl 显示 block 满足查询条件的时候才去访问 row 数据。一旦去读row 数据，就根本不再关心 lock byte 或者itl 了。

lock  byte是给 dml 用的，不是给查询用的。 [/B]

那么是不是下面第2、3步可以省略了呢？


1. Read the Data Block.

2. Read the Row Header.

3. Check the Lock Byte to determine whether there's an ITL entry.

4. Read the ITL entry to determine the Transaction ID (Xid).

..............

biti_rainy

最初由 solearn 发布
[B]


那么是不是下面第2、3步可以省略了呢？


1. Read the Data Block.

2. Read the Row Header.

3. Check the Lock Byte to determine whether there's an ITL entry.

4. Read the ITL entry to determine the Transaction ID (Xid).

.............. [/B]

这个文档是个老外写的，在这个位置是错误的。

solearn

最初由 biti_rainy 发布
[B]

这个文档是个老外写的，在这个位置是错误的。 [/B]

My God.

这样就顺畅了。这里困惑了N久。谢谢biti。