Oracle 数据库隔离级别，特性，问题和解决方法

若是没有任何数据库隔离策略，在多用户（多事务）并发时，会产生下列问题：
　　- 丢失更新（lost update）：两个事务同时更新同一条数据时，会发生更新丢失。
　　　　例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户B读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户A把姓名更改成“王小明”（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B把年龄更改成33（学号=107，姓名=“小明”，年龄=33）
　　　　=> 用户A提交（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B提交（学号=107，姓名=“小明”，年龄=33）
　　　　用户A对学生姓名的更新丢失了。
　　- 脏读（dirty read）：当一个事务读取另外一个事务还没有提交的修改时，产生脏读。
　　　　例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
　　　　=> 用户A把姓名更改成“王小明”（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户B读取学号为107的学生（学号=107，姓名=“王小明”，年龄=28）
　　　　=> 用户A撤销更改，事务回滚（学号=107，姓名=“小明”，年龄=28）
　　　　这样用户B至关于读取了一个从未存在过的数据“王小明”。若是涉及到金额的话问题更为严重，由于用户B读取了一个金额以后，极可能把这个金额与其它金额累加，再把结果保存到汇总数据之中，这样在月底对不上帐的时候，因为用户A回滚了事务，数据库内不会有任何操做记录，这样用户B是什么时候、从哪里读取了错误数据根本无从查起。
　　- 不可重现的读取（nonrepeatable read）：同一查询在同一事务中屡次进行，在此期间，因为其余事务提交了对数据的修改或删除，每次返回不一样的结果。
　　　　例如：假设学生表里只有“小明”和“小丽”2条记录（小明.年龄=20，小丽.年龄=30）。若是用户A把“小明.年龄”更改成40、把“小丽.年龄”更改成50并提交事务。在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。
如今考虑在用户A更新 2 名学生的年龄时，用户B执行了一个计算平均年龄的事务：

如前所述，在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。用户B计算得出的平均年龄是 25 或 45 都是能够接受的，可是在上例中用户B计算得出的平均年龄 35 是从未出如今系统中的错误数值。
　　- 幻读（phantom read）：同一查询在同一事务中屡次进行，因为其余提交事务所作的插入操做，虽然查询条件相同，每次返回的结果集却不一样。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了肯定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，致使两次筛选的结果不一致。

隔离级别

　　为避免上述并发问题，ANSI/ISO SQL92标准定义了一些隔离级别：

　　- 读取未提交数据（read uncommitted）

　　- 读取已提交数据（read committed）

　　- 可重现的读取（repeatable read）

　　- 序列化（serializable）

经过指定不一样的隔离级别，可避免上述一种或多种并发问题，见下图。

细心的读者可能已经注意到上图不包括“丢失更新（lost update）”，这是由于“丢失更新”问题须要使用乐观锁或悲观锁来解决，超出本文范围，先不详述。

Oracle 的隔离级别

　　SQL92定义的隔离级别在理论上很完善，可是 Oracle 显然认为在实际实现的时候并不该该彻底照搬SQL92的模型。 
　　- Oracle不支持 SQL92 标准中的“读取未提交数据（read uncommitted）”隔离级别，想要脏读都没可能。
　　- Oracle 支持 SQL92 标准中的“读取已提交数据（read committed）”隔离级别，（这也是Oracle默认的隔离级别）。
　　- Oracle不支持 SQL92 标准中的“可重现的读取（repeatable read）”隔离级别，要想避免“不可重现的读取（nonrepeatable read）”能够直接使用“序列化（serializable）”隔离级别。
　　- Oracle 支持 SQL92 标准中的“序列化（serializable）”隔离级别，可是并不真正阻塞事务的执行（这一点在后文还有详述）。
　　- Oracle 还另外增长了一个非SQL92标准的“只读(read-only)”隔离级别。

Oracle的序列化（serializable）隔离级别

　　序列化，顾名思义，是让并发的事务感受上是一个挨一个地串行执行的。之因此说是“感受上”，是由于当2个事务并发时，Oracle并不会阻塞其中一个事务去等待另外一个事务执行完毕再执行，而是仍然让2个事务同时并行，那么如何能“感受”是串行的呢？请看下图的实验。

用户B的事务由于指定了serializable隔离级别，因此虽然在查询费用明细表以前，用户A提交了对费用明细表的更改，可是由于用户A提交的更改是在用户B的事务开始以后才提交的，因此这个更改对用户B的事务不可见。也就是说，用户B的事务开始以后，其它事务提交的更改都不会再影响事务内的查询结果，这样感受上用户A的事务好像是在用户B的事务结束以后才执行的似的。这原本是很是好的一个特性，极大地提升了并行性，可是也会形成问题。

　　问题1：Oracle的这种“假串行”会让严格依赖于时间的程序产生混乱。

　　请看下图这个例子，对费用结算的例子稍稍作了一点改动。

程序员的本意是统计2012-3-4这天从零点至运行程序之时的费用总额。若是他觉得 Oracle 的 serializable 会像 C# 的 lock 同样阻塞其它事务的话，就会对结果很是吃惊：在2012-3-4 0:00 ~ 2012-3-4 10:02 实际有3条费用明细，总额为20+30+100=150，而不是用户B的事务统计得出的50。

　　问题2：ORA-08177 Can't serialize access for this transaction (没法序列化访问)错误。

　　若是你使用了 serialize 隔离级别，没准你的客户会常常抱怨这个随机出现的错误。兄弟，你并不孤独！
　　致使这个错误的缘由有2个：
　　(1) 两个事务同时更新了同一条数据。你能够这样重现这个错误：事务B开始（使用serialize 隔离级别) => 事务A开始，更新 表1.RowA 但不提交 => 事务B更新表1.RowA，由于行锁定而被阻塞 => 事务A提交 => 事务B报 ORA-08177 错误。
　　(2) 事务所更新的表的 initrans 参数过小。Oracle 官方文档的说法是，若是使用了 serialize 隔离级别，表的 initrans 参数最小要设置成3（默认是1）。

alter table 费用明细表 initrans 3;

　　原文：“Oracle Database stores control information in each data block to manage access by concurrent transactions. Therefore, if you set the transaction isolation level to SERIALIZABLE, then you must use the ALTER TABLE command to set INITRANS to at least 3. This parameter causes Oracle Database to allocate sufficient storage in each block to record the history of recent transactions that accessed the block. Higher values should be used for tables that will undergo many transactions updating the same blocks.”
　　注意，人家说的是“最小是3”。我用本身笔记本里的 32 位 Oracle10g 测试的结果是设置成 3 也会频繁地报 ORA-08177 错误。后来改为5 和 10，都不行。改为50，终于不报错了。可是都说了这个错误是随机的，有时候3也没问题的——反过来讲，设置成50也未必保险。坑爹啊！真坑爹！！这就像菜谱里面写的“放入适量的油……”，他喵的到底多少算是“适量”啊？！！！
　　有兴趣的读者可使用下图的语句实际测试一下。

　　个人建议是，仍是尽可能不要用 serialize 隔离级别吧，用户是不会理解什么叫“没法序列化访问”的，他只会以为你的“XX功能会随机地很差用”却是真的。稍后咱们再简单讨论一下不用 serialize 隔离级别如何避免幻读。如今先来看一下 Oracle 官方文档建议的适合使用 serialize 隔离级别的3种状况。

　　(1) With large databases and short transactions that update only a fewrows（大数据库、只更新几条数据的短事务）

　　(2) Where the chance that two concurrent transactions will modify thesame rows is relatively low（2个并发事务更新同一条数据的概率不大）

　　(3) Where relatively long-running transactions are primarily read only（相对运行时间较长的事务主要用来读取数据）

使用默认的 read committed 隔离级别，如何避免幻读产生的问题

　　使用默认的 read committed 隔离级别，如何编写程序才能避免幻读产生的问题呢？首先，不管是“不可重现的读取（nonrepeatable read）”仍是“幻读（phantom read）”，都是由于程序反复读取数据产生的。因此首先须要作的是，在一个事务里确保只读取数据一次。最好用C#而不是存储过程实现业务逻辑，这样很容易作到只读取一次，而后把结果存放到IList或IDictionary里。比较难办的是须要更新数据的状况。回顾一下前面所举的幻读的例子。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了肯定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，致使两次筛选的结果不一致。要避免这个问题，仍是要贯彻“只读取一次”的原则，或者更广义地说，是“只肯定一次筛选范围”。大体有2种方法。
　　<法一> 能够先把符合条件的费用明细读取出来保存到一个列表里，而后不管统计仍是更新，都局限于这个列表里的数据。下面的C#代码与上图的功能相同，可是没有幻读的问题。

// 用户B的事务开始  IList<费用明细> chargeList = 费用明细Repository.获取未结算列表();
费用结算 balance = new 费用结算 
{
    总金额 = chargeList.Sum(t => t.金额),
    结算编号 = "J122" };
费用结算Repository.Save(balance); // 这时候用户A提交了一条新的费用明细，不过不要紧  foreach(费用明细 charge in chargeList)
{
    charge.是否已结算 = 1;
    charge.结算编号 = "J122";
    费用明细Repository.Update(charge);
}

这个方法的缺点是要对 chargeList 里的每一个实体 Update 一次，若是数据量较大可能会有性能问题。这时候能够用<法二>。
注 本文为了表述的方便使用了中文和英文混杂的代码，实际编程的时候不要这样作。
　　<法二> 使用事务B独有的方法标识出操做数据的范围。

注 虽然上图是用SQL语句来演示的，使用C#（实体+ORM）一样能够用这种方法。

严格依赖时间的程序

严格来讲这并非幻读形成的问题——事务A还没提交呢。这种设计十分危险，不管使用 read committed 仍是 serializable 隔离级别都不足以免并发形成的不一致，应该尽可能避免这样的设计。依赖时间很危险，由于系统时间是随时可能被系统管理员更改的，更别提有些国家和地区会实行夏时制，想一想看，事务B提交了以后，系统时间被回拨了1小时！
　　然而世事每每不尽如人意，你可能不幸遇到了这样一个遗留系统，或者用户有不少其它的业务或与你交互的系统严格依赖于时间而逼得你不得不这么作的时候，该怎么办呢？
　　<法一> 在业务逻辑层面，能够把用户B和用户A的两个方法使用C#提供的线程同步技术串行化——理论上行的通，可是操做费用明细实体的方法那么多，很容易有所遗漏。
　　<法二> 在Repository层面，为费用明细实体设置一个令牌，而且能够设置是否进入令牌模式。在令牌模式下，费用明细Repository里面的全部持久化操做都必须拿到令牌才能操做，拿不到令牌直接抛异常。平时的业务操做都在非令牌模式下工做。在用户B想要进行结算操做时，事务开始以后，立刻设置成令牌模式，而后获取令牌，这样就能确保此时只有用户B才能操做费用明细表了。此法虽然并发性不好，可是既简单又保险。并且不少时候像结算这样的操做一个月（或一天）只进行一次，并发性差一些也能够忍受。值得注意的是下面这种状况。

虽然发生的几率不高，可是让令牌法完全失效了。综合考虑系统时间被管理员改变的可能性，仅仅在结算事务里独占令牌也是不够的，还必须在费用明细Repository.Save()方法里验证费用明细.建立时间必须大于最近一次的结算时间。