DB2 for Linux, UNIX, and Windows 的锁事件，第 1 部分: 分析 DB2 for Linux, UNIX, and Windows 中的锁等待情形

核心提示： -applications 输出与 -dynamic 输出之间的映射很简单：应用程序 34（处于锁等待状态）当前正在执行当前锚 ID 195 和当前语句 ID 1 所标识的 SQL 语句，在 db2pd -dynamic 输出的 Dynamic SQL Statements 部分中，DB2 fo

-applications 输出与 -dynamic 输出之间的映射很简单：

应用程序 34（处于锁等待状态）当前正在执行当前锚 ID 195 和当前语句 ID 1 所标识的 SQL 语句。在 db2pd -dynamic 输出的 Dynamic SQL Statements 部分中，那些 ID 可以映射到以下 SQL 语句：

清单 11. 应用程序 34 执行的 SQL 语句

UPDATE　EMPLOYEE　SET　SALARY　=　SALARY　*　0.02　

持有锁的应用程序 30 最近执行的 SQL 语句是最近锚 ID 60 和最近语句 ID 1 所标识的 SQL 语句。那些 ID 可以映射到以下 SQL 语句：

清单 12. 应用程序 30 执行的 SQL 语句

UPDATE　EMPLOYEE　SET　BONUS　=　SALARY　*　0.1　WHERE　JOB　=　'MANAGER'　

注意，db2pd -dynamic 输出包含另一个通常难以发现的有趣信息：Dynamic SQL Environments 部分的列 Iso 中显示了被执行的动态 SQL 语句的隔离级别（UR = Uncommitted Read，CS = Cursor Stability，RS = Read Stability，RR = Repeatable Read）。

我们来总结一下 DBA 就用户 B 的应用程序被挂起的原因有什么发现：

挂起是由表 EMPLOYEE 上一个独占式的行锁导致的。

持有锁的事务属于用户 A 执行的一个应用程序。而用户 B 的事务正在等待那个锁。

两条有冲突的语句都是表 EMPLOYEE 上的 UPDATE 语句。

有了这些信息，DBA 可以开始采取一些必要的步骤来解决锁等待状况，例如建议用户 A 终止事务，或者强制关闭用户 A 的应用程序。此外，可以采取措施避免将来出现那样的状况，例如配置 DB2 控制器（governor），使之自动终止运行时间过长的事务。

在这个示例场景中，db2pd 被连续执行数次，每次使用一个单独的选项。现实中不会出现这样的情况。相反，db2pd 只被调用一次，调用时同时使用前面介绍的所有选项：