http://space.itpub.net/17203031/viewspace-756336
在各种事务级别中，Oracle实现的是“Read Committed”，也就是读取的数据都是已经提交过的数据内容。在Oracle中，select不会阻塞任何操作，同样也不会被任何其他操作阻塞。
Oracle的select动作是不会加锁的，也不会受到数据表已经有锁的影响。其他操作，如insert、update和delete，通常会有两个锁定动作，一个是对数据表的共享锁，保护数据表结构不被DDL操作修改。另一个锁定动作是独占锁，独占修改删除的数据记录和对应的Undo段地址。
如果Oracle需要保证在其他会话在修改数据块，尚未提交的时候，一个会话select数据，还满足“Read Committed”，就必须要在一个地方保存住数据块的“前镜像”，也就是rollback segment/undo segment的作用。
当一个数据块进行修改的时候，Oracle会自动将前镜像信息保存在一个rollback/undo空间里面，数据块中包含一个寻址到rollback/undo位置，这个位置就是ITL（活动事务槽）。当事务没有结束，select操作到这个数据块的时候，会通过ITL找到前镜像信息，并且拼凑出数据块的前镜像信息。
另一个方面问题，如果一个select开始后，由于数据量的原因，持续很长时间。在这个时间段内发生了DML操作，比如删除了几条数据并且提交，那么select操作检索的范围中，会不会包括这几条数据呢？
下面我们通过实验来证明。
1、环境准备
我们选择11gR2环境进行实验。
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 – Production
--创建实验数据表
13:35:25 SQL> create table t as select * from dba_objects where rownum<100;
Table created
Executed in 0.124 seconds
实验有一个重点，就是如何让一个数据查询持续很长时间，由于环境的限制，笔者不能拿到一个长时间操作的数据范围。所以，采用了一些变通方法。
set time on;
set serveroutput on;
declare
coun number;
cursor tes is select * from t;
t_info t%rowtype;
begin
coun := -1;
open tes;
loop
fetch tes into t_info;
coun := coun + 1;
dbms_lock.sleep(0.1);
exit when tes%notfound;
end loop;
dbms_output.put_line('Total Count: '||to_char(coun));
end;
/
代码中的部分就是使用游标逐条的fetch数据表t记录。关键部分在于dbms_lock方法sleep，它可以实现让代码终止一段时间，模拟长时间操作处理。这样，我们就可以在另一个会话中更从容的进行操作了。
2、一致读DML操作实验
下面我们进行DML操作实验，如果一个select很长时间，并且中间有已经提交的DML修改操作，如插入、删除，select的结果会有什么影响？
首先，我们在会话1里面执行select过程脚本。
会话1：
14:16:22 SQL> set time on;
14:16:22 SQL> set serveroutput on;
14:16:22SQL> declare
2 coun number;
3 cursor tes is select * from t;
4 t_info t%rowtype;
5 begin
6 coun := -1;
7
8 open tes;
9 loop
10 fetch tes into t_info;
11 coun := coun + 1;
12 dbms_lock.sleep(1);
13
14 exit when tes%notfound;
15 end loop;
16 dbms_output.put_line('Total Count: '||to_char(coun));
17 end;
18 /
Total Count: 99
PL/SQL procedure successfully completed
Executed in100.044seconds
同时，第二个会话再执行脚本，注意相应的时间。
会话2：
14:15:54 SQL> set time on;
14:16:25SQL> delete t;
99 rows deleted
Executed in 0.016 seconds
14:16:29SQL> commit;
Commit complete
Executed in 0 seconds
14:16:31 SQL>
在第二个会话中，我们实现了14:16:29的时候提交了事务。此时任何select动作，都应该是不能访问到数据。
但是，第一个会话的启动时间是14:16:22，此时数据是存在的。执行了超过100秒之后，才运行结束。返回结果是99行，明显是有结果的。
之后，第一个会话再执行的时候，我们就再也看不到数据了。
14:18:03 SQL> select count(*) from t;
COUNT(*)
----------
0
Executed in 0.031 seconds
这就是典型的Oracle一致读过程。无论select持续多长时间，Oracle都会保证返回的数据SCN版本都是在发出select语句时的SCN。比如，当发出select命令的时候，SCN编号是1000，那么在检索数据表段的时候，只会去检索那些SCN小于等于1000的数据行记录。如果当前数据行正有事务信息，就会根据ITL查找Undo/Rollback中的前镜像。如果数据行的SCN大于1000，那么会去Undo/Rollback找那些Expired的记录。
所以，在过去手工管理Rollback的时候，如果一个select时间很长，同时数据修改频度很高，会报错1555错误，也就是Snapshot Too Old。在现在自动Undo管理的时候，这样的场景已经很少了。
3、Cross DDL
那么，我们想到一个场景，如果我们在长时间select的时候，发出DDL语句，如Truncate、Drop数据表。因为select操作不会加锁，所以不能组织DDL操作（独占六级锁）。
我们还是通过实验来证明。首先，我们恢复一下现场。
14:21:35 SQL> insert into t select * from dba_objects where rownum<100;
99 rows inserted
Executed in 0.032 seconds
14:23:05 SQL> commit;
Commit complete
Executed in 0.016 seconds
第一个会话，启动匿名块脚本。
14:23:27 SQL> set time on;
14:23:27 SQL> set serveroutput on;
14:23:27SQL> declare
2 coun number;
3 cursor tes is select * from t;
4 t_info t%rowtype;
5 begin
6 coun := -1;
7
8 open tes;
9 loop
10 fetch tes into t_info;
11 coun := coun + 1;
12 dbms_lock.sleep(1);
13
14 exit when tes%notfound;
15 end loop;
16 dbms_output.put_line('Total Count: '||to_char(coun));
17 end;
18 /
Total Count: 99
PL/SQL procedure successfully completed
Executed in99.997seconds
第二个会话，进行drop数据表过程。
14:16:31 SQL> set time on;
14:23:30 SQL> drop table t purge;
Table dropped
Executed in 0.047 seconds
执行drop数据表动作。开始时间为14:23:30，持续不到1s。但是在第一个会话中，开始14:23:27，持续了100s。说明，在第一个会话结束之前，数据表就已经不存在了。
但是，从第一个会话结束的情况看，数据表还是存在的。第二次执行一次，第一个会话报错。
14:25:07 SQL>
14:25:19 SQL> set time on;
14:25:19 SQL> set serveroutput on;
14:25:19 SQL> declare
2 coun number;
3 cursor tes is select * from t;
4 t_info t%rowtype;
5 begin
6 coun := -1;
7
8 open tes;
9 loop
10 fetch tes into t_info;
11 coun := coun + 1;
12 dbms_lock.sleep(1);
13
14 exit when tes%notfound;
15 end loop;
16 dbms_output.put_line('Total Count: '||to_char(coun));
17 end;
18 /
declare
coun number;
cursor tes is select * from t;
t_info t%rowtype;
begin
coun := -1;
open tes;
loop
fetch tes into t_info;
coun := coun + 1;
dbms_lock.sleep(1);
exit when tes%notfound;
end loop;
dbms_output.put_line('Total Count: '||to_char(coun));
end;
ORA-06550:第3行,第31列:
PL/SQL: ORA-01775:同义词的循环链
ORA-06550:第3行,第17列:
PL/SQL: SQL Statement ignored
ORA-06550:第4行,第10列:
PLS-00201:必须声明标识符'T'
ORA-06550:第4行,第10列:
PL/SQL: Item ignored
ORA-06550:第10行,第20列:
PLS-00320:此表达式的类型声明不完整或格式不正确
ORA-06550:第10行,第5列:
PL/SQL: SQL Statement ignored
报错。
说明，对于DDL操作（Truncate相同），一致读的现象依然存在。Oracle不会因为同时的DDL操作，影响到原来已经发出的select动作。从原理上，笔者认为还是和Undo/Rollback有关。
对于Truncate数据表，Oracle没有修改真正的数据，而是修改了段头信息，直接修改段头的分区extent信息。这部分动作其实也是会计入到Undo/Rollback空间，并且段信息data_object_id被修改。
当原有data_object_id访问需求出现的时候，Oracle会找Undo/Rollback上的段头信息，找到原有的Extent分区列表，进而可以范围数据。
4、结论
本篇演示了一致读现象，不仅对于DML操作有效，对DDL同样有效。