DB2 9.5 中的锁定超时分析新方法

核心提示： 这个锁定超时报告的开始部分与前面看到的相同，但是，DB2 9.5 中的锁定超时分析新方法(7)，这次的 Lock Owner 部分包含额外的、有价值的信息，在标题 List of Inactive SQL Statements from current UOW 下边，结束语本文介绍了 DB

这个锁定超时报告的开始部分与前面看到的相同。但是，这次的 Lock Owner 部分包含额外的、有价值的信息。在标题 List of Inactive SQL Statements from current UOW 下边，可以看到在发生锁定超时之前锁持有者的事务执行的所有 SQL 语句。从这组 SQL 语句中，可以找到导致问题锁定的语句。在这个场景中，使用 UPDATE 语句增加每个员工的工资。

注意，这个功能是对结合使用 db2cos 和 db2pd 方法的一个重大改进。使用 db2cos 与 db2pd 相结合的方法，只能看到锁持有者的应用程序执行的最后一条语句 — 在这个场景中是对 EMPLOYEE 表的查询。但是由于查询并没有导致出现问题的独占锁，您仍然不知道是哪条语句导致了锁定。使用新方法 — DB2_CAPTURE_LOCKTIMEOUT 和死锁事件监视器 — 您拥有在锁拥有者的事务中执行的所有 SQL 语句的历史信息，这就可以将 UPDATE 确定为相关的语句。

使用锁定超时报告的提示

带有语句历史功能的死锁事件监视器适用于所有应用程序，会增加 DB2 数据库管理程序对监视器堆的大量使用。所以应该谨慎使用。您应该始终首先设置 DB2_CAPTURE_LOCKTIMEOUT=ON，然后只在必要的时候使用 DETAILS HISTORY 选项激活死锁事件监视器。

使用锁定超时报告时，您可能会注意到，DIAGPATH 中的锁定超时报告文件的数量在持续增加。DB2 不会删除这些报告文件，所以 DBA 需要删除它们或者将它们移动到不同的位置，以便在 DIAGPATH 的文件系统上始终有足够的空间。

即使拥有了锁定超时报告功能，也不是总能够轻松确定出导致锁定超时的原因。例如，如果锁定超时由静态 SQL 或 DB2 内部锁定引起时，就没有那么容易确定原因。DB2 9.5 文档的 Lock timeout reporting 一章提供了这些局限性的一个简短列表。但是，DB2 9.5 中的锁定超时报告绝对是一个许多 DBA 期待已久的功能，而且将大大简化对锁定超时的分析。

结束语

本文介绍了 DB2 9.5 中全新的锁定超时报告功能。将这个新功能与 “Analyzing lockwait situations in DB2 for Linux, UNIX, and Windows” 中描述的方法进行比较，演示了这个新的 DB2 9.5 特性的强大之处。