Overview of Oracle Database Transaction Isolation Levels
- Oracle 数据库提供如下事务隔离级别：
- 已提交读隔离级别
- 可串行化隔离级别
- 只读隔离级别
Read Committed Isolation Level
- 在（默认的）已提交读隔离级别中，事务中执行的每个查询，仅看到在查询开始之前提交的数据，而不是事务开始之前提交的数据。这一隔离级别适合于几乎不可能发生事务冲突的数据库环境
- 已提交读事务中的查询可以避免读取在查询过程中所提交的数据。例如，如果一个查询正扫描到一个百万行表的一半，而另一个不同的事务对第 950000 行提交了一个更新，但当查询读到第 950000 行时，它并不能看见这个变化。然而，由于数据库不会阻止其它事务修改一个查询所读取的数据，其他事务可能会在查询执行期间更改数据。因此，两次运行相同查询的事务可能会出现模糊读和幻想读现象
Read Consistency in the Read Committed Isolation Level
- 为每个查询提供一个一致的结果集，保证数据一致性，无需用户采取任何行动。对于隐含的查询（如在一个 UPDATE 语句中的 WHERE 子句），也同样可以保证其一致的结果集。但是，在隐式查询中的每个语句不会看到 DML 语句本身所做的更改，只能看到更改之前所存在的数据
- 如果 SELECT 列表中包含一个 PL/SQL 函数，则数据库在该 PL/SQL 函数代码内运行的 SQL 的级别（而不是在父 SQL 级别）上应用语句级别读一致性。例如，一个函数可能会访问某个表，其数据被另一个用户更改并提交。每次运行函数中的 SELECT 语句，都会建立一个新的读一致性快照
Conflicting Writes in Read Committed Transactions
- 在一个已提交读事务中，当事务尝试更改由另一个未提交并发事务（有时称为阻塞事务）所更新的行时，会发生写冲突。读提交事务将等待阻塞事务结束并释放其行锁。有两个选项如下所示：
- 如果阻塞事务回滚，正在等待的事务将继续并更改之前被锁定的行，就像另一个事务从未存在一样
- 如果阻塞事务提交并释放了锁，则正在等待的事务将对这个刚被更新的行继续其预定更新
- 表 9-2 显示了一个可能是可串行化的或已提交读的事务 1，如何与另一个已提交读的事务 2 进行交互。表 9-2 显示了一个称为丢失更新（lost update）的典型情况。事务 1 所作的更新不能在表中反映出来，即使事务 1 已经提交它。制定一项策略以处理丢失更新是应用程序开发的一个重要部分
Serializable Isolation Level
- 在可串行化隔离级别，事务只看到自事务开始以来（而不是自查询以来）该事务本身所提交的更改。可串行化事务运行在使其看起来好像没有其他用户在修改数据库中的数据的环境中
- 可串行化隔离适合如下环境：
- 大型数据库中只更新少数几行的短事务
- 两个并发事务将修改相同的行的可能性相对较低
- 较长时间运行的事务主要是只读事务
- 在可串行化隔离级别，在语句级别所获得的读取一致性通常延伸到整个事务范围。当重新读取在同一事务中之前读取的任何行时，保证结果相同。可以保证任何查询在该事务的持续期间返回相同的结果，因此其他事务所做的更改是不可见的，无论该查询已运行了多长时间。可串行化事务不会遇到脏读、模糊读取、幻读
- Oracle 数据库允许可串行化事务修改行，只要可串行化事务开始时，由其它事务对行所做的更改已提交。当一个可串行化事务试图更新或删除某数据，而该数据在串行化事务开始后被另一个不同的事务更改并提交，则数据库将生成一个错误：
ORA-08177: Cannot serialize access for this transaction - 当可串行化事务失败产生错误时，应用程序可以采取以下几种：
- Commit the work executed to that point
- 也许要先回滚到事务中之前建立的某保存点，然后执行一些其他额外 的（不同）语句
- 回滚整个事务
- 表 9-3 显示了一个可串行化事务与其它事务之间的交互。如果可串行化事务不会尝试更改由另一个事务在该可串行化事务开始后所提交的行，就可以避免可串行化访问问题
Read-Only Isolation Level
- 只读隔离级别类似于可串行化隔离级别，但只读事务不允许数据在事务中被修改，除非该用户是 SYS。因此，只读事务不会受到 ORA-08177 错误的影响。只读事务可用于生成报表，其内容必须与事务开始时保持一致
- Oracle 数据库通过从 undo 段中重建数据，来实现读取一致性。因为 undo 段是循环使用的，数据库可以覆盖 undo 数据。长时间运行的报表可能有一定的风险，读一致性所需要的 undo 数据可能已被一个不同的事务重用，并抛出快照太旧（snapshot too old）错误。设置一个 undo 保留期，即在旧数据被覆盖之前，数据库尝试保留 undo 数据的最短时间，以期避免这一问题
官方文档的参考链接 http://docs.oracle.com/cd/E11882_01/server.112/e40540/consist.htm#CNCPT621