单用户访问数据库和多用户访问数据库

使用单用户数据库时，每个事务都是顺序执行的，而不必应付与其它事务的冲突。但是，在多用户数据库环境下，多个事务可以同步执行，并且每个事务都有可能与其它正在运行的事务发生冲突。在多用户环境下，如果不将事务彼此隔离开来，就会发生四种现象：

丢失更新：
这种事件发生在两个事务读取和尝试更新同一数据时，其中一个更新会丢失。例如：事务 1 和事务 2 读取同一行数据，并都根据所读取的数据计算出该行的新值。如果事务 1 用其新值更新该行以后，事务 2 又更新了同一行，则事务 1 所执行的更新操作就丢失了。由于设计的方法，DB2 通用数据库不允许发生此类现象。

脏读：
当事务读取尚未提交的数据时，就会发生这种事件。例如：事务 1 更改了一行数据，而事务 2 在事务 1 提交更改之前读取了已更改的行。如果事务 1 回滚该更改，则事务 2 就会读取被认为是不曾存在的数据。

不可重复的读：
当一个事务两次读取同一行数据，但每次获得不同的数据值时，就会发生这种事件。例如：事务 1 读取了一行数据，而事务 2 在更改或删除该行后提交了更改。当事务 1 尝试再次读取该行时，它会检索到不同的数据值（如果该行已经被更新的话），或发现该行不复存在了（如果该行被删除的话）。

幻像：
当最初没有看到某个与搜索条件匹配的数据行，而在稍后的读操作中又看到该行时，就会发生这种事件。例如：事务 1 读取满足某个搜索条件的一组数据行，而事务 2 插入了与事务 1 搜索条件匹配的新行。如果事务 1 再次执行产生原先行集的查询，则会检索到不同的行集。

维护数据库一致性和数据完整性，但又允许多个应用程序同时访问同一数据，这样的特性称为并发性。DB2 通用数据库尝试用来强制执行并发性的方法之一是通过使用隔离级别，它决定在第一个事务访问数据时，如何对其它事务锁定或隔离该事务所使用的数据。DB2 通用数据库使用下列隔离级别来强制执行并发性：

可重复的读（Repeatable Read）
读稳定性（Read Stability）
游标稳定性（Cursor Stability）
未提交的读（Uncommitted Read）
我们将在接下来依次讨论每种级别。
“可重复的读”隔离级别

当使用可重复的读隔离级别时，在单个事务执行期间锁定该事务引用的所有行。使用这种隔离级别时，同一事务多次发出的同一个 select 语句将始终产生同一结果；丢失更新、脏读、不可重复的读、幻像都不会发生。

使用可重复的读隔离级别的事务可以多次检索同一行集，并可以对它们执行任意次操作，直到由提交或回滚操作终止事务；不允许其它事务执行插入、更新或删除操作，因为这些操作会在隔离事务存在期间影响正在被使用的行集。为了确保在“可重复的读”隔离级别下运行的事务所访问的数据不会受其它事务的负面影响，所以锁定了该隔离事务所引用的每个行 — 而不是仅锁定被实际检索和／或修改的那些行。因此，如果一个事务扫描了 1000 行但只检索 10 行，则所扫描的 1000 行（而不仅是被检索的 10 行）都会被锁定。

那么在现实环境中这个隔离级别是如何工作的呢？假定您拥有一家大型旅馆，并有一个网站，该网站按“先到先服务”的原则接受客户的房间预订。如果您的旅馆预订应用程序是在“可重复的读”隔离级别下运行的，当客户检索某个日期段内的所有可用房间列表时，您将无法更改那些房间在指定日期范围内的费用，而其他客户也将无法进行或取消将会更改该列表的预订，直到生成该列表的事务终止为止。（对于第一个客户的查询所指定范围之外的任何房间，您都可以更改房价，其他客户也都可以进行或取消房间预订。）
“读稳定性”隔离级别
当使用读稳定性隔离级别时，在单个事务执行期间，会锁定该事务所检索的所有行。当使用这种隔离级别时，直到隔离事务终止之前，其它事务不能更改隔离事务读取的所有行。此外，其它事务对其它行所作的更改，在提交之前对于运行在“读稳定性”隔离级别下的事务而言是不可见的。因此，当使用“读稳定性”隔离级别时，在同一事务中多次发出 select 语句可能会产生不同的结果。丢失更新、脏读和不可重复的读都不会发生；但是，有可能出现幻像。

使用“可重复的读”隔离级别时，隔离事务引用的每一行都被锁定；但是，在“读稳定性”隔离级别下，只锁定隔离事务实际检索和／或修改的行。因此，如果一个事务扫描了 1000 行但只检索 10 行，则只有被检索到的 10 行（而不是所扫描的 1000 行）被锁定。

那么，这种隔离级别会如何改变旅馆预订应用程序的工作方式呢？现在，当一个客户检索某个日期段内的所有可用房间列表时，您可以更改旅馆中任何房间的房价，而其他客户也可以取消在第一个客户的查询所指定的日期段内所保留房间的预订。因此，如果在终止提交查询的事务之前再次生成列表，则产生的新列表中有可能包含新的房价或第一次产生列表时不可用的房间。
“游标稳定性”隔离级别
当使用游标稳定性隔离级别时，只要隔离事务所用的游标定位在某一行上，就会锁定该游标所引用的这一行。所获取的锁一直有效，直到游标重定位（通常通过调用 FETCH 语句）或隔离事务终止为止。因此，当使用这种隔离级别时，在同一事务中多次发出 select 语句可能会产生不同的结果。丢失更新和脏读不会发生；但有可能出现不可重复的读和幻像。

当使用“游标稳定性”隔离级别的事务通过可更新游标从表中检索行时，在游标定位在该行上时，其它事务不能更新或删除该行。但是，如果被锁定的行本身不是用索引访问的，那么其它事务可以将新的行添加到表，并对位于被锁定行前后的行进行更新和／或删除操作。此外，如果隔离事务修改了它检索到的任何行，那么在隔离事务终止之前，即使在游标不再位于这个被修改的行，其它事务不能更新或删除该行。


其它事务在其它行上进行的更改，在提交之前对于使用“游标稳定性”隔离级别的事务是不可见的。缺省情况下，大多数事务都使用“游标稳定性”隔离级别。

这种隔离级别对旅馆预订应用程序有什么影响呢？现在，当一个客户检索某个日期段内的所有可用房间列表，然后查看关于所产生的列表上每个房间的信息时（每次查看一个房间），您可以更改旅馆中任何房间的房价，而其他客户可以对任何日期段的任何房间进行或取消预订；唯一的例外是第一个客户当前正在查看的房间。当第一个客户查看列表中另一个房间的信息时，对于这个新房间也是一样；您现在可以更改第一个客户刚才查看的房间的房价，其他客户也可以预订该房间，但不能对第一个客户当前正在查看的房间进行这些操作。
“未提交的读”隔离级别
在使用未提交的读隔离级别的情况中，当单个事务检索行时，仅当另一个事务试图删除或更改被检索的行所在的表时，才会在单个事务期间锁定这些行。因为在使用这种隔离级别时，行通常保持未锁定状态，所以丢失更新、脏读、不可重复的读和幻像都可能会发生。

在大多数情况下，其它事务对行所作的更改，在提交或回滚之前对于使用“未提交的读”隔离级别的事务是可见的。但是，此类事务不能看见或访问其它事务所创建的表、视图或索引，直到那些事务被提交为止。类似地，如果其它事务删除了现有的表、视图或索引，使用“未提交的读”隔离级别的事务仅当进行删除操作的事务终止时才能了解这一情况。这种行为有一个例外：当运行在“未提交的读”隔离级别下的事务使用可更新游标时，该事务的行为和在“游标稳定性”隔离级别下运行一样，并应用“游标稳定性”隔离级别的约束。

“未提交的读”隔离级别通常用于那些访问只读表的事务和／或某些执行 select 语句的事务，这些语句对其它事务的未提交数据没有负面效果。

那么这种隔离级别对旅馆预订应用程序有什么影响呢？现在，当一个客户检索某个日期段内的所有可用房间列表时，您可以更改旅馆中任何房间的房价，而其它客户也可以对任何日期段内的任何房间进行或取消预订。此外，如果其它客户取消了预订，即使他们还没有终止其事务并将那些取消提交到数据库，所生成的列表就可以包含这些取消预订的房间了。
指定隔离级别
尽管隔离级别是控制如何为事务锁定资源的，但实际上是在应用程序级别指定它们的。对于嵌入式 SQL 应用程序，是在预编译时或将应用程序绑定到数据库时指定要使用的隔离级别。在大多数情况下，应用程序的隔离级别是用受支持的编译语言（如 C 或 C++）编写的，通过 PRECOMPILE PROGRAM 和 BIND 命令／API 的 ISOLATION 选项来设置隔离级别。对于调用级接口（CLI）应用程序，所用的隔离级别是在应用程序运行时通过调用指定了 SQL_ATTR_TXN_ISOLATION 连接属性的 SQLSetConnectAttr() 函数进行设置的。也可以通过指定TXNISOLATION 关键字的值来设置 CLI 应用程序的隔离级别，该关键字位于 db2cli.ini 配置文件中。对于 JDBC 和 SQLJ 应用程序，隔离级别是在应用程序运行时通过调用驻留在 java.sql 连接接口中的 setTransactionIsolation() 方法设置的。

当没有指定隔离级别时，则缺省地使用“游标稳定性”隔离级别。对于从命令行处理器（CLP）执行的命令和脚本以及嵌入式 SQL、CLI、JDBC 和 SQLJ 应用程序都是如此。因此，也可以指定从 CLP 运行的命令和脚本所用的隔离级别；在这种情况下，所用的隔离级别是通过在建立与数据库的连接之前在 CLP 中执行 CHANGE ISOLATION 命令设置的。
选择适当的隔离级别
选择用于事务的适当隔离级别是非常重要的。隔离级别不仅影响数据库如何很好地支持并发性；而且影响包含该事务的应用程序的整体性能。这是因为获取和释放锁所需的资源因隔离级别而异。

通常，使用的隔离级别越严格，对并发性提供的支持就越少，而整体性能可能会越低，因为要获取并占有更多的资源。但是，当您确定将要使用的最佳隔离级别时，应该通过确定哪些现象可接受而哪些现象不可接受来进行决策。下列推断可以用来帮助您确定在特定环境中使用哪种隔离级别：

如果您正在只读数据库上执行查询，或者正在执行查询而不考虑是否有未提交的数据值返回，则使用“未提交的读”隔离级别。（需要是只读事务 — 不需要较高的数据稳定性。）

如果您希望在不看见未提交数据值的情况下获得最大的并发性，则使用“游标稳定性”隔离级别。（需要是读／写事务 — 不需要较高的数据稳定性。）

如果您希望获得并发性，并希望限定的行在单个事务执行期间保持稳定，则使用“读稳定性”隔离级别。（需要是只读或读／写事务 — 需要较高的数据稳定性。）

如果您正在执行查询，并且不希望看到对产生的结果数据集进行更改，则使用“可重复的读”隔离级别。（需要是只读事务 — 需要极高的数据稳定性。