分析 DB2 for Linux, UNIX, and Windows 中的锁等待情形
2008-10-07 16:16:32 来源:WEB开发网对于数据库级的事件或故障,默认的 db2cos 脚本用 -db 和 -inst 选项调用 db2pd。DBA 用一个 db2pd 调用替换相应的行,该调用收集锁超时分析所需的监视器数据:
清单 21. 更改 db2cos 脚本,以收集用于锁超时分析的数据
if %DATABASE%. == . goto no_database
db2pd -db %DATABASE% -locks wait -transactions -agents -applications -dynamic
>> %DIAGPATH%db2cos%PID%%TID%.%DBPART%
goto exit
现在,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 内容的一个有用的工具。
更多精彩
赞助商链接