在具体介绍隔离级别之前，谈谈为什么要有隔离级别。数据库作为应用的核心组件，除了保证数据一致性之外，另一个很重要的指标就是并发性（也是很多数据库对外宣传的口号）。但中所周知，数据库高的一致性比如避免脏数据，保证数据可重复读，或者可串行化，都需要进行一定的数据隔离，这也就意味着加锁，加锁肯定会丧失并发性。所以为了保证并发性，提出了不同的隔离级别，或者叫做弱化的一致性。这些隔离级别在不同的数据库中的表现方式各异，对性能的影响也各有差异，远没有表面看上去那么简单。
Oracle的隔离级别分为Read Committed，Serializable，Read Only，其中前两种是ANSI/ISO SQL92标准定义的隔离级别。它不支持Read Uncommited,它在Read Committed级别支持一个很好的特性，读一致性（这个一般在IOS级别的Repeatable Read级别支持）。不过Oracle的Read Committed不能完全代替Repeatable Read，因为它不能避免“第二类丢失更新”（这种在Repeatable Read中会报错的）。我们可以在应用层通过乐观锁来避免”第二类丢失更新“，这也就是说当你选择一款数据库的时候也在一定程度上决定了程序的设计。
下面分别介绍各个隔离级别的特点：
Read Committed 读已提交：
- 不会出现脏读、第一类丢失更新（回滚其他事务已提交的数据）；
- 支持语句级的读一致性；例如在统计一个表的数据时及时这些数据发生了变更也能得到正确的结果（查询发起时刻的结果）。这个是通过多版本技术实现的。
- 读不会阻塞写。在读数据时不会对数据加锁。
- 在Insert/Update时（1）如果有未提交的有冲突的项，则阻塞。（2）如果有已提交的有冲突的则报错。
- 可以实现语句级别的查询一致性：同一个语句得到的结果肯定是数据库中某个时刻的一致的结果。
- 不保证多个语句查询的一致性：例如分别查明细和汇总表，得到的结果可能是不一致的。
- 如何保证查询结果后续未被更新（避免第二类丢失更新）：（1）采用乐观锁（vno等）当更新失败时报错；（2）采用Select for update 查询，以保证记录级的锁定。此语句的隔离效果和直接更新但未提交一样。
- 如何实现数据库级最大并发：更新时采用“字段调用”或其改进方法。
Serailizable 可串行化：
- Oracle利用多版本化技术可以做到在你问之前（执行sql之前）已经知道答案了，从而保证可串行化。而不是采用锁的技术，采用锁的技术性能会很差。
- 支持可重复读、不允许幻想读（是指多次统计或范围读取仍能得到一致的结果）、第二类丢失更新（提交时覆盖别人已提交的数据，天然支持，无需使用乐观锁等技术）。
- 读不会阻塞写。
- 如果读取时某个数据已经被更新了，数据库会利用UNDO日志恢复到事务开始时刻，并返回那时的结果。如果根据UNDO日志无法恢复，则报错ORA-0155:snapshot too old。
- 如果更新时发现某个数据已经被更新，则报错ORA-08177:can’t Serailize access for this transaction。可以看出如果要使用此级别，(1) 一般要保证没有其他人修改相同的数据； (2) 需要事务级的读一致性；（3) 事务都很短（有利于保证第1点）。
- 此隔离级别下无法看到其他事务提交的所有更新，包括已经提交的。如果应用需要保证数据完整性可能会有问题，因为其他事务可能已经修改了事务，但你却看不到。
- 此隔离级别不意味着所有事务就是像一个接一个串行执行一样。例子参见。
Read Only 只读级别：
和Serailizable级别一致，只是不允许进行数据库更新操作。
其他一些注意事项：
1.热表的超出预期的IO：
由于Oracle利用多版本技术来保证读取数据的一致性，在对热表进行读操作时，在Serailizable隔离级别（或是需要执行很长时间的sql时）下可能会导致读取大量的UNDO块来恢复数据，从而导致大量的IO。
2.update重启动：
如果在更新时部分数据已经被其他事务更新（Read Committed级别），此时Oracle会回退update，然后尝试使用Select for update模式进行重启动更新。一般情况下这对应用是透明的，但是有些数据如触发器等是不能回滚的，另外如果我们的更新记录数过大重启动更新还是很影响效率的。
参考资料：