1、consistent read（读一致性）的通俗理解 首先介绍 undo 中的简单结构：undo headertransaction tableundo 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 is
2、pac: 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.读取数据块，如果该块在内存中，则增加一个克隆用于 undo2.读取行头：tab 0, row 0, 0x1e4c tl: 44 fb: -H-FL- lb: 0x1 cc: 83.检查 lb 是否这里有一个 itl：Itl Xid Uba Flag 0x01 xid: 0x0003.000.00000010 ub
3、a: 0x02000004.0005.09 -4.如果有，则读取这个 itl 的 xid，xid=us#.slot#.wrap#5.读取交易表，如果这个交易已经提交（state=9 表示提交）并且有了一 scn 小于当前查询的system change number,那么 clean out 这个块，继续下一个块（如果需要的话）并且返回第一步。（在每一个查询的时候都将产生一个查询scn，在该 scn 一下的 commit scn 都认为对应的交易已经提交）TRN TBL: index state cflags wrap# uel scn dba nub - 0x00 10 0xc0 0x001
4、0 0x0000 0x0000.00075fec 0x02000004 0x00000001 0x01 9 0x00 0x000f 0x0002 0x0000.00075f77 0x00000000 0x000000006.如果没有提交，那么读取最新改变的 undo block 根据 transaction table 中显示的dba（该地址为 undo entries 中最新改变的块）7.对比这个块的交易号同交易表中的交易号。如果在 undo block 中的交易号不等于交易表中的交易号，那么报告错误：ORA-01555 “Snapshot Too Old.”.xid: 0x0001.01d
5、.000023a4 seq: 0x2a7 cnt: 0x3f irb: 0x3f icl: 0x0 flg: 0x0000Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset-0x01 0x1f68 0x02 0x1ee8 0x03 0x1e68 0x04 0x1de8 0x05 0x1d680x06 0x1cec 0x07 0x1c6c 0x08 0x1bec 0x09 0x1b6c 0x0a 0x1aec0x0b 0x1a6c 0x0c 0x19f0 0x0d 0x1970 0x0e 0x18f0 0x0f 0x18740x10 0x
6、17f8 0x11 0x1778 0x12 0x16f8 0x13 0x1678 0x14 0x15f88.如果这个块的交易号等于交易表中的交易号，那么从这个 undo entry 的头开始，应用改变到块上（该块为在内存中克隆的块）If the Transaction IDs are identical, make a copy of the data block in memory. Starting with the head undo entry, apply the changes to the copied data block. 9.如果这个 undo enties 的尾巴上有其他
7、的块地址（因为一个交易可能占用了好几个 undo 块），那么将这个 undo block读到内存中重复分析第七步和第八步。重复 7 和 8 步直到首先的 record 不在包含其他块的地址。10.当这里不再有前一个数据块的地址，那么这个交易就完全被 undo 了。（因为 undo 块是从最后一个块往前读的，这是为了保证在你读的时候，最新改变的数据都能在 undo 中体现）11.如果这个 undo entry 包含：a):包含一个指向前一个交易 undo block 的地址，读取这个交易的 id 号在这个前一个交易的undo block 头里并读取相应的交易表 entries，返回第五步。 re
8、cord 纪录也是从后往前读的，因此有 irb 指定先读取哪一个。* Rec #0x1 slt: 0x00 objn: 48636(0x0000bdfc) objd: 49636 tblspc: 33(0x00000021)* Layer: 11 (Row) opc: 1 rci 0x00Undo type: Regular undo Last buffer split: NoTemp Object: NoTablespace Undo: Nordba: 0x00801b7c- 这里有一个指针指向前一个 undo block 证明这个 undo chain 上还有一些 undo 块。*-KDO
9、 undo record:KTB Redoop: 0x02 ver: 0x01op: C uba: 0x00801b7c.02a7.3eKDO Op code: URP row dependencies Disabledxtype: XA bdba: 0x054016c1 hdba: 0x054016b9itli: 1 ispac: 0 maxfr: 4863tabn: 0 slot: 85(0x55) flag: 0x2c lock: 0 ckix: 0ncol: 8 nnew: 5 size: 0col 3: 3 c1 06 36col 4: 3 c1 06 36col 5: 1 30co
10、l 6: 2 c1 02col 7: 6 c4 02 23 38 39 3d*-* Rec #0x2 slt: 0x00 objn: 48636(0x0000bdfc) objd: 49636 tblspc: 33(0x00000021)* Layer: 11 (Row) opc: 1 rci 0x01Undo type: Regular undo Last buffer split: NoTemp Object: NoTablespace Undo: Nordba: 0x00000000-这里的 dba 因为rci 决定了它不是这个 block 的最后一个 record。这是因为，如果你查询的表有很多个交易在修改，那也需要读取这些所有的这些交易所涉及的undo block，应用到重做b):如果包含一个 ITL 纪录，存储这个 ITL record 到数据块（cr block），然后返回第四步。这里比较迷惑，为什么一个 undo entries 上还会包含一个 ITL 纪录呢？哪里来的？-一句话： 一致读就是 session 查询所读到的数据，是查询开始的时间点之前已经提交的数据+当时 session 自己做出变更还没有提交的数据。
