DB2锁兼容性和死锁（转）

DB2数据库中的锁相信大家都有一些了解，下文对DB2锁兼容性和死锁方面作了详尽的阐述，希望对您能够有所帮助。

AD： DB2锁兼容性是怎样的？死锁又是怎么回事？下文对这些问题都作了详细的解答，如果您在此方面遇到过类似的问题，不妨一看。

锁兼容性

如果数据资源上的一种锁状态允许在同一资源上放置另一个锁，就认为这两种锁（或两种状态）是兼容的。每当一个事务持有数据资源上的锁，而第二个事务请求同一资源上的锁时，DB2 数据库管理器检查两种锁状态以确定它们是否兼容。如果锁是兼容的，则将锁授予第二个事务（假定没有其它事务在等待该数据资源）。但是，如果锁不兼容，则第二个事务必须等待，直到第一个事务释放它的锁为止，然后才可以获取对资源的访问权并继续处理。（如果资源上有多个与新请求的锁不兼容的锁，则第二个事务必须等到它们全部被释放为止。）请参阅 IBM DB2 Universal Database Administration Guide：Performance 文档（或在 DB2 信息中心搜索 Lock type compatibility 主题）以获取关于各个锁之间是否兼容的特定信息。

锁升级 

所有的锁都需要存储空间；因为可用空间并不是无限的，所以 DB2 数据库管理器必须限制锁可以使用的空间（这是通过 maxlocks 数据库配置参数完成的）。为了防止特定数据库代理超过已建立的锁空间限制，当获取的（任意类型的）锁过多时，会自动执行称为锁升级的进程。锁升级是一种转换，它将同一表内几个单独的行级锁转换成一个单独的表级锁。因为锁定升级是在内部处理的，所以唯一可从外部检测到的结果可能只是对一个和多个表的并发访问减少了。

以下是锁定升级的工作原理：当事务请求锁，而锁存储空间已满时，就选定与该事务相关联的一个表，帮它获取一个表级锁，释放所有该表的行级锁（以在锁列表数据结构中创建空间），并将表级锁添加到锁列表。如果这个过程所释放的空间不够，则选定另一个表，重复这个过程，直到释放了足够的可用空间为止。这时，事务将获取所请求的锁并继续执行。但是，如果在该事务的所有行级锁都已经升级之后，仍然没有获得必要的可用锁空间，则（通过 SQL 错误代码）要求事务提交或回滚它启动以来所作的所有更改，然后事务终止。

死锁

有时两个或更多个事务对锁的争用会引起称为死锁的情况。说明死锁发生原因的最佳方式是举例说明：假定事务 1 在表 A 上获取了互斥（X）锁，而事务 2 在表 B 上获取了互斥（X）锁。现在，假定事务 1 尝试在表 B 上获取互斥（X）锁，而事务 2 尝试在表 A 上获取互斥（X）锁。这两个事务的处理都将被挂起，直到同意第二个锁请求为止。但是，因为在任何一个事务释放它目前持有的锁（通过执行或回滚操作）之前，（两者中的）任一事务的锁请求都不会被同意，而且又因为两个事务都不能释放它目前持有的锁（因为它们都已挂起并等待锁），所以两个事务都陷入了死锁状况。

当死锁状况发生时，除非某些外部代理采取行动，否则所涉及的所有事务将无限期地等待释放锁。DB2 通用数据库用于处理死锁的工具是称为死锁检测器的异步系统后台进程。死锁检测器的唯一职责是定位和解决在锁定子系统中找到的任何死锁。死锁检测器在大多数时间处于休眠状态，但会在预置的时间间隔被“唤醒”，以确定是否存在死锁状况。如果死锁检测器在锁定子系统中发现死锁，则选择死锁涉及的一个事务、终止并回滚它。（被终止和回滚的事务收到一个 SQL 错误代码，它所获得的所有锁都被释放。）通常，剩下的一个或多个事务就可以继续执行了。

锁超时

任何时候当一个事务在特定数据资源（例如，表或行）上持有锁时，直到持有锁的事务终止并释放它所获取的所有锁之前，其它事务对该资源的访问都可能被拒绝。如果没有某种适当的锁超时检测机制，则事务可能无限期地等待锁的释放。例如，有可能出现这种情况：一个事务在等待另一个用户的应用程序所持有的锁被释放，而该用户离开了他（或她）的工作站，但忘了执行一些允许应用程序终止拥有锁的事务的交互。显然，此类情况会导致极差的应用程序性能。要避免发生此类情况时阻碍其它应用程序的执行，可以在数据库的配置文件中指定锁超时值（通过 locktimeout数据库配置参数）。使用之后，该参数就控制任何事务将等待获取所请求的锁的时间。如果在指定的时间间隔过去之后还未获得想要的锁，则等待的应用程序接收一个错误，并回滚请求该锁的事务。分布式事务应用程序环境特别容易产生此类超时；可以通过使用锁超时避免它们。

http://database.51cto.com/art/201011/232451.htm

补充：

从锁定的角度来看，所有事务通常归为以下几类之一：

• 只读：这是指只读性的事务，它们包含 SELECT 语句（它们本质上就是只读的）、指定了 FOR READ ONLY 子句的 SELECT 语句或意义虽不明确但因为在预编译和／或绑定过程中指定了 BLOCKING 选项而看作是只读的 SQL 语句。
• 倾向于更改：这是指有可能进行更改的事务，它们包含指定了 FOR UPDATE 子句的 SELECT 语句或者那些意义虽不明确但因为 SQL 预编译器解释它的方式而看作是倾向于进行更改的 SQL 语句。
• 更改：这是指一定会进行更改的事务，它们包含 INSERT、UPDATE 和／或 DELETE 语句，但不包括 UPDATE ... WHERE CURRENT OF ... 或 DELETE ... WHERE CURRENT OF ... 语句。
• 游标控制：这是指包含 UPDATE ... WHERE CURRENT OF ... 和 DELETE ... WHERE CURRENT OF ... 语句的事务。

只读事务通常使用意向共享（IS）和／或共享（S）锁。另一方面，倾向于更改的事务将更新（U）、意向互斥（IX）和互斥（X）锁用于表，将共享（S）、更新（U）和互斥（X）锁用于行。更改事务往往使用意向互斥（IX）和／或互斥（X）锁，而游标控制的事务通常使用意向互斥（IX）和／或互斥（X）锁。

当 SQL 语句准备执行时，DB2 优化器研究各种满足该语句请求的方法，并估计每种方法所涉及的执行成本。然后，DB2 优化器根据这一评估选择它认为最优的访问计划（访问计划指定满足 SQL 请求所需的操作，以及执行这些操作的顺序）。访问计划可以使用两种方法之一来访问表中的数据：通过直接地读取表（称为执行表 或关系扫描）；或通过读取该表上的索引，然后检索特定索引项所引用的表行（称为执行索引扫描）。

DB2 优化器选择的访问路径（通常是根据数据库的设计确定的）会对所获取锁的数目和所使用的锁状态产生显著的影响。例如，当使用索引扫描来查找特定行时，DB2 数据库管理程序极有可能获取一个或多个意向共享（IS）行级锁。但是，如果使用表扫描，因为必须依次扫描整个表来找到特定行，所以 DB2 数据库管理程序可能会选择获取单个共享（S）表级锁。

结束语

本教程旨在介绍数据一致性的概念，以及 DB2 9 在单用户和多用户环境下用来维护数据库一致性的各种机制。如果用户忘记了进行所有必要的更改，或者如果在用户进行更改的过程中系统崩溃了，又或者数据库应用程序由于某种原因过早地停止了，数据库都会变得不一致。当几个用户同时访问同一数据库时，也可能发生不一致的情况。例如，一个用户可能在适当地更新所有表之前读取另一个用户的更改，并根据所读取的不是最终的数据值进行了一些不适当的操作或进行了错误的更改。为了防止数据不一致（尤其是在多用户环境中），DB2 9 的开发人员将下列数据一致性支持机制合并到其设计中：

• 事务
• 隔离级别
• 锁

事务（也称为工作单元）是一种将一个或多个 SQL 操作组织成一个单元的可恢复序列，通常位于应用程序进程中。事务的启动和终止定义了数据库一致性点；要么将事务中执行的所有 SQL 操作的结果都应用于数据库（提交），要么完全取消并丢弃已执行的所有 SQL 操作的结果（回滚）。在这两种情况下，数据库都保证在每个事务结束后处于一致的状态。

维护数据库一致性和数据完整性，同时又允许多个应用程序同时访问同一数据，这种特性称为并发性。在 DB2 中，并发性是通过使用隔离级别实现的。可以使用四种不同的隔离级别：

• 可重复的读
• 读稳定性
• 游标稳定性
• 未提交的读

可重复的读隔离级别可以防止所有现象，但是会大大降低并发性的程度（可以同时访问同一资源的事务数量）。未提交的读隔离级别提供了最大的并发性，但是脏读、不可重复的读和幻像都可能出现。

除了隔离级别，DB2 通过对锁的使用在多用户环境下提供并发性。锁是一种用来将数据资源与单个事务关联起来的机制，其用途是控制其他事务在资源与拥有锁的事务相关联的情况下如何与资源进行交互。可以使用几种不同类型的锁：

• 意向无（IN）
• 意向共享（IS）
• 下一键共享（NS）
• 共享（S）
• 意向互斥（IX）
• 带意向互斥的共享（SIX）
• 更新（U）
• 下一键弱互斥（NW）
• 互斥（X）
• 弱互斥（W）
• 超级互斥（Z）

为了维护数据完整性，DB2 数据库管理程序隐式地获取锁，获取的所有锁都在 DB2 数据库管理程序的控制之下。锁可以放置在表空间、表和行上。

为了进行优化以获取最大的并发性，行级锁通常比表级锁更好，因为它们所限制访问的资源要小得多。但是，因为所获取的每个锁都需要一定数量的存储空间和处理时间来进行管理，所以单个表级锁需要的开销比几个单独的行级锁低。