Oracle 事务隔离级别

先看一张Concepts中关于事务隔离级别的一张表格：

从上图可以看到：

通常事务的隔离级别定义为以下4种（基于3种在并发事务中需要避免的现象来划分的）：

1.Read uncommitted
        从字面意义可以看出，读取那些未提交的数据。事务1在事务进行过程中，会读到事务2修改了但是没有提交的数据，所以产生了 脏读（Dirty Read）。

2.Read committed
        读取提交的数据。事务1在事务开始后第1次查询了emp_id=1的emp_name=sean，然后事务2修改了emp_id=1的emp_name=king并提交，接着事务1第2次查询emp_id=1的emp_name=king。可见在事务1的整个过程中，2次查询同一条数据获得了不同的结果，因为只要提交的数据就能被看到。所以这种隔离级别不能避免 不可重复读（Nonrepeatable Read）。

3.Repeatable read
        字面意思是可以重复读，比照上例，就是在事务1的整个过程中，查询某一条数据总能获得相同的结果。但是不能避免 幻读（Phantom Read）。什么是幻读，和 不可重复读 的区别在哪里？想象这种情形，事务1第1次统计dept_id=20的员工总数为50，此时事务2往员工表插入1条新的员工记录并提交，事务1第2次查询dept_id=20的员工总数为51.发现2次统计的结果不一致。这种情况称之为 幻读。与 不可重复读的区别是，在此类场景中，事务1第1次读取的数据并没有被修改。而是新增了数据导致满足条件的数据发生了变化。所以 幻读 和 不可重复读 的区别就在于事务读取的数据是否发生了变化。

4.Serializable
        字面意思是串行化。在串行化隔离级别的时候，事务看到的都是事务开始那一刻的数据。举例说明。现在员工表中dept_id=20的员工总数为50。事务1开始后，第1次查询dept_id=20的员工总数为50，接着事务2删除了1条dept_id=20的员工并提交，事务1第2次查询dept_id=20的员工总数仍然为50（如果事务1隔离级别是2.Read committed，此时结果就会是49），接着事务3增加了2条dept_id=20的员工并提交，事务1第3次查询dept_id=20的员工总数仍然为50（如果事务1隔离级别是3.Repeatable read，此时看到的结果是52，删除属于数据发生了变化，所以不可见，但是新增2条记录可见）。串行化可以这么理解，就是任何一个事务都觉得数据库就他一个事务在串行执行，没有其他事务和他并行执行，没有其他事务，他看到的数据当然不会发生变化。

以上大致介绍了基于3种需要避免的现象而划分出的4种隔离级别。
Oracle支持 Read committed（默认） 和 Serializable 以及 Read only（数据库只读打开，和Serializable很像，但是禁止数据修改除非是sys用户）。
随着隔离级别的提高，数据库对于事务并发的支持能力会下降。对于Oracle默认情况下不能避免的 不可重复读 和 幻读 现象。在应用设计阶段应该考虑到。

下面演示几种场景：

--准备测试数据

SQL> drop table t purge;

SQL> create table t (id int);

SQL> insert into  t values(1);

SQL> insert into  t values(2);

SQL> insert into  t values(3);

SQL> commit;

SQL> select * from t;

        ID
----------
         1
         2
         3


--演示1、Read committed（默认隔离级别）演示，所有以下操作按时间顺序

--事务1 手动开启一个事务
SQL> set transaction isolation level read committed;

--事务1 查询表中数据
SQL> select * from t;

        ID
----------
         1
         2
         3

--事务2 删除一条数据并提交
SQL> delete from t where id=3;
SQL> commit;

--事务1 第2次查询表中数据，发现和第1次读取结果不一致，这就是 不可重复读 现象。
SQL> select * from t;

        ID
----------
         1
         2





--演示2、Serializable（隔离级别）演示，所有以下操作按时间顺序

--事务1 手动开启一个事务
SQL> set transaction isolation level Serializable;

SQL> select * from t;

        ID
----------
         1
         2

--事务2 增加2条数据并提交
SQL> insert into t select * from t;
SQL> select * from t;

        ID
----------
         1
         2
         1
         2

SQL> commit;

--事务1 再次查询表中数据，仍然只有2条数据，因为事务1在事务2之前开始，所以事务1只能看到的是事务开始那个时间的数据，其他都不可见
SQL> select * from t;

        ID
----------
         1
         2





--演示3、ORA-08177: can't serialize access for this transaction

--目前表中数据
SQL> select * from t;

        ID
----------
         1
         2
         3


--事务1 手动开启一个事务
SQL> set transaction isolation level Serializable;

--事务2 修改1条数据先不提交
SQL> update t set t.id=4 where id=3;
1 row updated.

--事务1 修改同一条数据
SQL> update t set t.id=4 where id=3;
事务被hang住了

--事务2 提交刚刚的修改
SQL> commit;
Commit complete.

--事务1 产生报错信息，我们知道事务1先于事务2开启，事务1开启时，表中是存在id=3这条记录的。当事务2修改这条记录并提交。
--事务1再去修改这条记录发现这条记录发生了改变导致修改失败。由此可见串行化的隔离级别并发性会大打折扣。
--前面我们说过，串行化就是事务觉得数据库里面就他一个人在做操作，当他要修改一个数据发现在事务开始后被别人修改了，就会报错。
SQL> update t set t.id=4 where id=3;
update t set t.id=4 where id=3
*
ERROR at line 1:
ORA-08177: can't serialize access for this transaction




Oracle®Database
Concepts
12c Release 1 (12.1)
E41396-14