《Oracle逻 辑读写深入分析》之分析逻辑读次数受哪些因素的影响（笔记）[以跟踪文件中的事件来计数consistent gets次数，非用公式计算]

跟踪文件里的一些字符串表示的意思：

kdstgr：表示数据块,即表对应的段中除了段头块外的块（存储数据行的）或是索引的对应的段中除了段头块外的块（存储索引条目的）。

Kdusru:  以当前模式读入，以用于更新操作（Read>（这里的（一致性读过程）例子是避免了用undo块来回滚数据这一情况的）

一、全表扫描 I
select *> //读取段头两次不是因为表里有两条数据行的关系，而是因为要进行一次>3.   
4.  2>7.   
8.  2 rows updated.   
9.   
10.  -- Session 2:   
11.  HELLODBA.COM>conn demo/demo   
12.  Connected.   
13.  HELLODBA.COM>alter system flush buffer_cache;   
14.   
15.  System altered.  
HELLODBA.COM>select * from tt;

                 1  recursive calls   
31.            0  db block gets   
32.           13  consistent gets   
33.            8  physical reads  
同样还是之前的那个小表的全表扫描，这里有 13 次逻辑读，比正常情况下多了 6 次。看看从跟踪文件中我们可以发现什么。
首先，和前面一样，它还是读取了 2 次段头（2 次读取表段头//读取段头两次不是因为表里有两条数据行的关系，而是因为要进行一次 kteinicnt 操作和 kteinpscan 操作的关系。），然后读取高水位线下的普通数据块（4 次读取表数据块）。当读取到（内存）地址为140e64f的普通数据块 时，这个数据块是第一块被读取到的含有被其他事务修改过数据的数据块。这时，Oracle读取了回滚段的段头（1 次读取回滚段头）中事务表（TransactionTable）的数据，从中找到用于一致性回滚的 UNDO 数据块。我们之前做了两次 UPDATE，尽管这两次的 UNDO 内容都在同一个 UNDO 数据块中（从 UBA 可以看出，有兴趣的读者可以将这个 UNDO 块 dump 出来进行观察），这里有两次’Applying CR undo’，每一条 ITL  entry 都导致了增加了一次对 UNDO 数据块的读（2 次读取UNDO 数据块。）。至此，已经完成了 9 次逻辑读：2 次读取表段头，4 次读取表数据块，1次读取回滚段头，2 次读取 UNDO 数据块。

注释：这里，2 次读取UNDO 数据块，是假设该被修改的普通数据块里的被修改的数据行是只是被一个事务所修改，是被该事务里的两次操作所修改