一致性读（Consistent Reads）与buffer cache
[English]
作者：
fuyuncat
来源：
www.HelloDBA.com
分享到
在一致性读（Consistent Read）过程中，Oracle根据SCN从undo segment/buffer中读取脏数据块的undo数据来保证查询数据的一致性。当查询读取了CR数据块时，为了提高后续CR的性能，会将CR块copy到buffer中，后续的CR就直接读取buffer。
在分析CR buffer之前，先简单看下buffer cache是怎么管理的。
我们知道，buffer cache的主要目的就是缓存那些被访问过的数据，以提高下次对这些数据的访问性能。由于一个数据库的被访问的数据量是很庞大的，但是buffer cache资源是有限的，这就需要一个对buffer cache的管理算法，以大大提高buffer cache的利用率。这一算法就是LRU算法，其基本思想就是让那些经常被访问的数据能尽量长时间的保留在buffer中，以提高数据库的整体性能。
Oracle通过两个链表来实现这种算法的管理：LRU List和Write List（也叫Dirty List）。在LRU List中，链接的是所有空闲块（Free Buffer）、正在被使用的块（Pinned Buffer）以及所有还未被放到Write List中去的脏块（Dirty Buffer）。当一个数据块被访问到了时，就会被放到LRU链表的MRU（the Most Recently Used）端，这样，那些很少被访问到的数据块就会逐渐移动到了链表的LRU（the Least Recently Used）端。当需要访问一个数据块时，用户进程会先搜索（通过hash）LRU List，看该数据块是否已经被cache住，如果有，就直接使用（buffer hit），如果没有（Buffer Miss），服务进程会从LRU List的LRU端开始搜索空闲块，并且在搜索过程中，将找到的脏块都转移到Write List上去。如果搜索一定数量（一个内部的Threshold值）的buffer块还没有找到空闲块时，服务进程就会发信号给DBW0进程将脏数据块写入磁盘并释放。
回过来再说CR。CR是发生在多个事务对相同数据进行读写时，为了保证读进程不因为时间差（query消耗的时间）而造成数据差异，让读进程读取到与本身时间戳（SCN）相符的数据块镜像。在发生CR时，CR块也会被cache到buffer中，以提高query后续的对该数据块的一致性读的效率，此时的CR buffer块会打上相应query的SCN标志，该数据块也只能被这个query使用。那么，具体什么样的情况会发生CR呢？我们通过代码演示来分析发生CR的各种情况。
注：下面是测试表t_cr的创建脚本：
SQL> create table t_cr as select * from user_objects;表已创建。SQL> alter table t_cr add constraint r_cr_pk primary key (object_id);表已更改。注：下面查询中objd是表对象的data_object_id，不是object_id，该值可以从dba_objects中查到。
一、什么情况下发生CR
· 在“读”事务开始时，数据块已经被其他事务修改但未被提交，但在数据块被读取到之前，修改已经被提交：
时间：
T1
T2
T3
T4
A事务
Block Updated
Commit
C事务
Query begin
Read Block(Consistent Read)
B:SQL> alter system flush buffer_cache;系统已更改。SQL> select objd,file#,block#,status,dirty from v$bh where objd=186467 and block#= 147146 and status !='free';未选定行
A事务更新数据，未提交：
A:SQL> update sys.t_cr set object_name = 'NB' where object_id=20;已更新 1 行。
修改过的数据块被cache到了buffer中：
B:SQL> select objd,file#,block#,status,dirty from v$bh where objd=186467 and block#= 147146 and status !='free';OBJD FILE# BLOCK# STATUS DI---------- ---------- ---------- -------------- --186467 1 147146 xcur Y
C事务开始query，query时间较长，运行中且未读取到被A事务修改过的数据块：
C:SQL> select to_char(count(1)) from user_objects, user_tables2 union all3 select object_name from sys.t_cr where object_id=20;(Query运行中......)
A事务提交修改
A:SQL> commit;提交完成。
这时，C事务读取到该数据块，对数据块的读取是一致性读（CR），其读取的数据是修改前的数据：
C:(Query完成)TO_CHAR(COUNT(1))-----------------------------------------------------------------------159390AAA
看到UNDO数据被copy到了buffer cache中作为CR buffer存在：
B:SQL> select objd,file#,block#,status,dirty from v$bh where objd=186467 and block#= 147146 and status !='free';OBJD FILE# BLOCK# STATUS DI---------- ---------- ---------- -------------- --186467 1 147146 xcur Y186467 1 147146 cr N
再次读取就是修改后的数据：
C:SQL> select object_name from sys.t_cr where object_id=20;OBJECT_NAME-----------------------------------------------------------NB
· “读”事务开始之前，数据块被其他事务修改，当“读”事务读取到该数据块时，修改仍未提交，发生一致性读：
时间：
T1
T2
T3
T4
A事务
Block Updated
Commit
C事务
Query begin
Read Block(Consistent Read)
B:SQL> alter system flush buffer_cache;系统已更改。
A事务修改数据、未提交：
A:SQL> update sys.t_cr set object_name = 'AAA' where object_id=20;已更新 1 行。
C事务读取数据块，发生一致性读
C:SQL> select object_name from sys.t_cr where object_id=20;OBJECT_NAME--------------------------------------------------------------NB
CR块被cache：
B:SQL> select objd,file#,block#,status,dirty from v$bh where objd=186467 and block#= 147146 and status !='free';OBJD FILE# BLOCK# STATUS DI---------- ---------- ---------- -------------- --186467 1 147146 xcur Y186467 1 147146 cr N
以上这两种情况可以视为同一种情况：
当数据块在某个事务中被修改了，所有开始于“修改”事务开始后、提交前的所有会读取到该数据块的“读”事务，在读取到该数据块时都会发生一致性读。
· “读”事务开始后、在读取数据块之前，数据块被其他事务修改且未提交，当读取到该数据块时仍未提交：
时间：
T1
T2
T3
T4
A事务
Block Updated
Commit
C事务
Query begin
Read Block(Consistent Read)
B:SQL> alter system flush buffer_cache;系统已更改。
C事务开始query，query时间较长，运行中且未读取到被即将被A事务修改的数据块：
C:SQL> select to_char(count(1)) from user_objects, user_tables2 union all3 select object_name from sys.t_cr where object_id=20;(Query运行中......)
A事务修改数据块，未提交
A:SQL> update sys.t_cr set o