分析DB2 for Linux，UNIX，and Windows中的锁等待情形

核心提示：现在，db2cos 脚本已准备好，分析DB2 for Linux，UNIX，and Windows中的锁等待情形(4)，DBA 可以坐等下一次锁超时事件的发生，假设像之前描述的那样，以便在出现锁超时事件时捕捉它们，您学习了如何配置出现锁超时事件时 db2cos 脚本的自动调用，用户 A 与 B 之间发生相同的锁情形，但

现在，db2cos 脚本已准备好，DBA 可以坐等下一次锁超时事件的发生。

假设像之前描述的那样，用户 A 与 B 之间发生相同的锁情形。但是，这一次设置了 LOCKTIMEOUT，因此过了 10 秒（LOCKTIMEOUT = 10）之后用户 B 的事务被回滚。用户 B 通知 DBA 回滚自己的事务，并且收到 SQL 错误消息 -911 和原因码 68（SQL code -911 / reason code 68 = locktimeout）。于是，DBA 检查通过自动调用 db2cos 脚本收集到的监视器数据。

首先，DBA 用锁超时内部错误码调用 db2diag，以确定锁超时发生的确切时间：

清单 22. 在 db2diag.log 中检查锁超时事件的时间点

db2diag -g data:=-2146435004
2006-12-18-14.27.24.656000+060 I6857H409　　　　　LEVEL: Event
PID　　 : 2968　　　　　　　　 TID　: 2932　　　　PROC : db2syscs.exe
INSTANCE: DB2　　　　　　　　　NODE : 000　　　　 DB　 : SAMPLe
APPHDL　: 0-21　　　　　　　　 APPID: *LOCAL.DB2.061226132544
AUTHID　: FECHNER
FUNCTION: DB2 UDB, lock manager, sqlplnfd, probe:999
DATA #1 : <preformatted>
Caught rc -2146435004.　Dumping stack trace.

db2diag.log 条目显示，在 2006-12-18-14.27.24.656000 时发生了一次锁超时。由于 db2cos 脚本将它的输出写到 %DIAGPATH% 中的 db2cos%PID%%TID%.%DBPART% 文件中，DBA 有望在实例的诊断路径中找到一个 db2cos29682932.0 文件：

%DIAGPATH% = instance's diagnostic path = on Windows by default C:Program FilesIBMSQLLIBDB2

%PID% = process ID = 2968（如 db2diag.log 条目中所示）

%TID% = thread ID = 2932（也显示在 db2diag.log 条目中）

%DBPART% = database partition = 0（在一个非分区数据库环境中）

那个文件的内容很像本文第一部分中逐步考察的那个 db2pd 监视器输出，DBA 可以通过它来识别锁超时的原因。

捕捉到锁超时后，DBA 可以通过 -catch clear 选项调用 db2pdcfg 来禁用 db2cos 脚本：

清单 23. 再次使用 db2pdcfg 清除错误捕捉设置

db2pdcfg -catch clear
All error catch flag settings cleared.

结束语

本文演示了如何使用 db2pd 实用程序进行锁等待监视。本文借助一个示例场景展示了 DBA 如何通过检查不同 db2pd 选项的输出来识别并发问题的原因。从 DB2 9 开始，可以将 db2pd 与新的 db2cos 脚本一起使用，以便在出现锁超时事件时捕捉它们。您学习了如何配置出现锁超时事件时 db2cos 脚本的自动调用。本文还介绍了 db2diag 实用程序 —— 这是用于检查 db2diag.log 内容的一个有用的工具。