Oracle 数据库隔离级别，特性，问题和解决方法 - 1-2-3 - 博客园
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()方法里验证费用明细.创建时间必须大于最近一次的结算时间。