1.一致性读：
假设从9点时发出一条查询，此查询语句运行了一分钟，那么查询的是9点时表内信息，如果在9时至9：00：30之间修改并提交了数据，查询语句扔查询结果仍是9点时的表内的数据。
实验步骤如下：
在SESSION1中发出查询语句（增加条件延长查询语句运行时间）
在SESSION2中修改并提交。（需要在SESSION1查询语句运行期间进行）
SESSION1:
9:26:50 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
16
18
19
10 rows selected
下面这条语句能够执行一分钟左右，在语句执行时，抓紧时间去SESSION2中提交修改的数据。
可以看到，查询出的是发出查询时表内的数据：
9:27:26 SQL> select * from test where a=7 and (select count(*) from dba_objects,dba_tables)>1 and (select count(*) from dba_objects,dba_tables)>2 ;
A
———-
7
9:28:05 SQL>
SESSION2:
9:27:13 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
16
18
19
10 rows selected
9:27:14 SQL> update test set a=a+7 where a=7;
1 row updated
9:27:54 SQL> commit;
Commit complete
9:27:57 SQL> SELECT * FROM TEST
A
———-
1
2
3
4
5
6
14
16
18
19
10 rows selected
9:28:50 SQL>
2.current read：
读取当前的 data block，最新的 data block，比如在update， delete的时候就总是current read。
因为要对最新的data block做更改，对过去更改没有实际意义。
执行过程描述：
session 1 开始了一个update 操作，通过consistent read（a=9） 获取了 数据块的id。使用WHERE后语句使得这个UPDATE操作需要持续很长时间。
session 2 在SESSION1的UPDATE未执行时，修改了 a=9 这一行的数据，变成了a=18
session 1 通过一个通过最开始查询a=9拿到的block id去以current read读取数据块，结果发现数据块不符合filter的条件a=9。所以 session 1没有更新。
session 1：
SQL> set time on
9:06:43 SQL> select a,DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) from test;
A DBMS_ROWID.ROWID_BLOCK_NUMBER(
———- ——————————
1 242
2 242
3 242
4 242
5 242
6 242
7 242
8 242
9 242
10 242
10 rows selected
在SESSION1执行以下语句，因为执行时间较长，大约要一分钟，在执行期间去SESSION2提交更改的数据。
9:10:15 SQL> update test set a=a+1 where a=9 and (select count(*) from dba_objects,dba_tables)>1;
0 rows updated
9:10:40 SQL>
9:14:04 SQL> select * from test;
A
———-
1
2
3
4
5
6
7
8
18
10
10 rows selected
9:14:10 SQL>
SESSION2:
SQL> set time on
9:07:48 SQL> update test set a=a+9 where a=9;
1 row updated
9:10:34 SQL> commit;
Commit complete
9:10:37 SQL>
