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

使用 db2pd 工具确定并发问题的原因

文档选项

打印本页

将此页作为电子邮件发送

英文原文
级别： 中级
Dirk Fechner, IT 服务专家, IBM Software Group
2008 年 9 月 27 日
当多个 DB2® 用户并发地访问一个数据库时，锁等待会导致响应变慢。锁等待是临时性的，因而难以捕捉。然而，当出现锁等待情形时，需要由数据库管理员负责确定锁等待的原因。本文通过例子演示如何使用用于 DB2 for Linux®, UNIX®, and Windows® 的 db2pd 和 db2pdcfg 实用程序完成该任务。
db2pd 是用于监视各种 DB2 数据库活动以及故障排除的实用程序。它是从 DB2 V8.2 开始随 DB2 引擎发布的一个独立的实用程序，其外观和功能类似于 Informix onstat 实用程序。db2pd 是从命令行以一种可选的交互模式执行的。该实用程序运行得非常快，因为它不需要获取任何锁，并且在引擎资源以外运行（这意味着它甚至能在一个挂起的引擎上工作）。通过快照监视还可以收集 db2pd 提供的很多监视器数据，但是 db2pd 和快照监视的输出格式却有很大不同。这使 DBA 可以选择更符合用户需求的监视替代方法。本文关注用于锁监视的 db2pd 选项。有一篇由 Sam Poon 撰写的 developerWorks 文章（参见参考资料 小节）对 db2pd 的监视功能作了更广泛的介绍。
下面的图展示了用于锁监视的 db2pd 选项：

TranHdl：用于指定事务句柄，以便只监视由特定事务持有的锁。 showlocks：这个子选项将锁名称扩展成有意义的解释。对于一个行锁，该选项显示以下信息：表空间 ID、表 ID、分区 ID、页和槽。通过使用编目视图 SYSCAT.TABLES 上的一个查询，很容易将表空间 ID 和表 ID 映射到相应的表名：
SELECT TABSCHEMA, TABNAME FROM SYSCAT.TABLES WHERE TBSPACEID = tbspaceid AND TABLEID = tableid
wait：如果指定 wait 子选项，则 db2pd 只显示事务当前正在等待的锁，以及对等待情形负责的锁。这个子选项大大简化了锁等待分析，因为它将输出限制为参与锁等待情形的锁。 db2pd database 和 file 选项不是特定于锁监视的，但是适用于（几乎）所有 db2pd 调用。database 选项将 db2pd 返回的监视器数据限制为某个数据库的监视器数据。而 file 选项则允许定义一个文件，以便将 db2pd 输出写到该文件。
接下来，我们开始使用前面介绍的 db2pd 选项来分析一个示例锁等待情形。为此，我们创建 DB2 SAMPLE 数据库：
db2sampl
用户 A 执行事务 A，以根据每个经理的薪水为他们提供 10% 的奖金：
UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = ‘MANAGER‘
当事务 A 仍然在运行（因为用户 A 还没有使用 COMMIT 或 ROLLBACK 终止该事务）时，用户 B 执行事务 B，以将每个雇员的薪水提高 2%：
UPDATE EMPLOYEE SET SALARY = SALARY * 0.02
由于事务 B 没有完成，用户 B 请求 DBA 确定问题的原因。于是，DBA 调用 db2pd，看是否存在锁等待情形：
db2pd -db sample -locks wait showlocks Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:33:05 Locks: Address TranHdl Lockname Type Mode Sts Owner Dur 0x050A0240 6 02000600050040010000000052 Row ..X W 2 1 0x050A0DB0 2 02000600050040010000000052 Row ..X G 2 1 HoldCount Att ReleaseFlg 0 0x00 0x40000000 TbspaceID 2 TableID 6 PartitionID 0 Page 320 Slot 5 0 0x00 0x40000000 TbspaceID 2 TableID 6 PartitionID 0 Page 320 Slot 5
db2pd 报告 ID 为 2 的表空间中一个 ID 为 6 的表上有一个行锁存在锁等待情形。通过检查 SYSCAT.TABLES，DBA 断定表 EMPLOYEE 上的确存在锁等待。
SELECT TABSCHEMA, TABNAME FROM SYSCAT.TABLES WHERE TBSPACEID = 2 AND TABLEID = 6 TABSCHEMA TABNAME -------------------------------------------------------------------------------- FECHNER EMPLOYEE 1 record(s) selected.
对于事务 2（列 TranHdl），db2pd -locks 输出的 status 列（Sts）显示一个 “G”。G 代表 “granted”，意即事务句柄为 2 的事务拥有行锁。此外，列 Mode 表明，事务 2 持有的是一个 X 锁。等待的事务（列 Sts 中显示 “W”（“wait”）的事务）是句柄为 6 的事务。该事务正在与事务 2 请求同一个行上的 X 锁。通过查看 Owner 列（显示事务 2 是锁的所有者）和比较 Lockname（对于 db2pd -locks 中的两个条目是相同的），可以看到这一点。
接下来，DBA 将事务句柄映射到应用程序。这可以使用另一个 db2pd 选项 -transactions 来完成：
db2pd -db sample -transactions Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:34:47 Transactions: Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2 0x05141880 30 [000-00030] 2 9 WRITE 0x00000000 0x00000 0x05144880 34 [000-00034] 6 5 WRITE 0x00000000 0x00000
这个 db2pd 调用的输出表明，事务 2（列 TranHdl）是由应用程序 30（列 AppHandl）执行的，而事务 6 是由应用程序 34 执行的。这两个事务都正在对数据库执行写更改（列 State = WRITE）。所以 DBA 现在知道，应用程序 30 正持有应用程序 34 所等待的锁。
要获得关于锁等待情形涉及的应用程序的更多信息，可使用 -agents 选项调用 db2pd。该选项打印代表应用程序运行的代理的信息。注意，-agents 是一个实例级选项，这意味着不需要指定一个数据库（实际上，当指定一个数据库时，db2pd 打印出一条警告，并忽略 database 选项）。
db2pd -agents Database Partition 0 -- Active -- Up 3 days 08:35:42 Agents: Current agents: 2 Idle agents: 0 Active coord agents: 2 Active agents total: 2 Pooled coord agents: 0 Pooled agents total: 0 Address AppHandl [nod-index] AgentTid Priority Type State 0x04449BC0 34 [000-00034] 3392 0 Coord Inst-Active 0x04449240 30 [000-00030] 2576 0 Coord Inst-Active ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt DBName 3916 USER_B db2bp.ex 43 43 NotSet SAMPLE 2524 USER_A db2bp.ex 153 14 NotSet SAMPLE
在 db2pd -agents 输出中，DBA 可以看到使用应用程序 30 和 34 的用户的 ID（列 Userid）：应用程序 30 是由 USER_A 执行的，而应用程序 34 是由 USER_B 执行的。只有当每个用户都有一个单独的数据库授权 ID 时，才可能出现那样的应用程序与用户 ID 之间的映射。通常，这对于在应用服务器上运行的应用程序是不可能的，因为这些应用程序使用连接池，连接不是个人化的。
关于每个应用程序的更多信息则由 db2pd 选项 -applications 提供：
db2pd -db sample -applications Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:36:14 Applications: Address AppHandl [nod-index] NumAgents CoorTid Status 0x04AF8080 34 [000-00024] 1 3940 Lock-wait 0x03841960 30 [000-00020] 1 2548 UOW-Waiting C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 195 1 0 0 *LOCAL.DB2.061122195637 0 0 60 1 *LOCAL.DB2.061122195609
Status 列确认了 DBA 已经知道的一些东西：应用程序 34 处在锁等待状态。但是这并不新鲜，于是 DBA 将注意力集中在列 C-AnchID/C-StmtUID 和 L-AnchID/L-StmtUID 上。“C” 代表当前（current），“L” 代表最近（last）的锚 ID/语句 UID。这些 ID 可用于标识应用程序最近执行的 SQL 语句和应用程序当前执行的语句。为此，可以用 -dynamic 选项调用 db2pd。该选项显示数据库动态语句缓存的内容：
db2pd -db sample -dynamic Database Partition 0 -- Database SAMPLE -- Active -- Up 3 days 08:37:39 Dynamic Cache: Current Memory Used 187188 Total Heap Size 1271398 Cache Overflow Flag 0 Number of References 2 Number of Statement Inserts 3 Number of Statement Deletes 0 Number of Variation Inserts 2 Number of Statements 3 Dynamic SQL Statements: Address AnchID StmtUID NumEnv NumVar NumRef NumExe 0x056CEBD0 60 1 1 1 1 1 0x056CE850 180 1 0 0 0 0 0x056CFEA0 195 1 1 1 1 1 Text UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 WHERE JOB = ‘MANAGER‘ SET CURRENT LOCALE LC_CTYPE = ‘de_DE‘ UPDATE EMPLOYEE SET SALARY = SALARY * 0.02 Dynamic SQL Environments: Address AnchID StmtUID EnvID Iso QOpt Blk 0x056CECD0 60 1 1 CS 5 B 0x056D30A0 195 1 1 CS 5 B Dynamic SQL Variations: Address AnchID StmtUID EnvID VarID NumRef Typ 0x056CEEB0 60 1 1 1 1 4 0x056D3220 195 1 1 1 1 4 Lockname 010000000100000001003C0056 01000000010000000100C30056
-applications 输出与 -dynamic 输出之间的映射很简单：
应用程序 34（处于锁等待状态）当前正在执行当前锚 ID 195 和当前语句 ID 1 所标识的 SQL 语句。在 db2pd -dynamic 输出的 Dynamic SQL Statements 部分中，那些 ID 可以映射到以下 SQL 语句：
UPDATE EMPLOYEE SET SALARY = SALARY * 0.02
持有锁的应用程序 30 最近执行的 SQL 语句是最近锚 ID 60 和最近语句 ID 1 所标识的 SQL 语句。那些 ID 可以映射到以下 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 只被调用一次，调用时同时使用前面介绍的所有选项：
db2pd -db sample -locks wait showlocks -transactions -agents -applications -dynamic -file db2pd.out -repeat 15 40
产生的输出由针对每个选项的输出组成，各部分输出之间的顺序与各选项在 db2pd 调用中的顺序一致。而且，请注意 db2pd 调用最后的 2 个附加选项：
-file 表明 db2pd 输出应该被写到一个文件。在示例调用中，输出被写到文件 db2pd.out 中。 -repeat 表明 db2pd 应该每隔 15 秒执行一次，共执行 40 次（即每隔 15 秒执行一次，共执行 10 分钟）。每次执行的输出被附加到 -file 选项指定的文件后面。
-file 和 -repeat 选项对于在一段时间内监视数据库活动比较有用。对于锁等待分析，这两个选项可以帮助捕捉只存在一小段时间的锁等待情形。例如，如果数据库参数 LOCKWAIT 被设置为 20 秒，一个等待锁的事务在过了 20 秒的等待时间后被回滚。为了捕捉那样的锁等待情形，db2pd 的时间间隔必须设置为比 20 秒更短的时间间隔，例如例子中的 15 秒。
有时候，锁等待情形会导致锁超时，而锁超时又会导致事务被回滚。锁等待导致锁超时所需的时间段由数据库配置参数 LOCKTIMEOUT 指定。锁超时分析最大的问题是，不知道下一次的锁超时何时发生。为了捕捉死锁，可以创建一个死锁事件监视器。每当出现死锁时，这个死锁事件监视器便写一个条目。但是，对于锁超时就没有类似的事件监视器。所以到 DB2 9® 为止，捕捉锁超时的惟一方法还是连续的 db2pd 或快照监视（对于 db2pd，和前面解释的一样，-file 和 -repeat 选项可用于连续的锁监视）。
DB2 9 包含了一种新的机制，用于在数据库出现故障或发生事件时收集监视器数据：db2cos 脚本。为了捕捉锁超时事件，可以配置数据库，使之每当出现锁超时时启动 db2cos 脚本。在 db2cos 脚本中，和前面讨论的一样，可以以相同的选项调用 db2pd。我们来看一个示例场景，该场景演示了如何用 db2cos 脚本捕捉锁超时。
对于这个场景，假设 DBA 将数据库锁超时值设为 10 秒：
UPDATE DB CFG FOR SAMPLE USING LOCKTIMEOUT 10
为了每当出现锁超时时启动 db2cos 脚本，DBA 调用 db2pdcfg 实用程序，如下所示：
db2pdcfg -catch locktimeout count=1
-catch 选项指定应该自动导致调用 db2cos 脚本的故障或事件。对于锁超时事件，可以指定字符串 locktimeout。或者，可以指定与锁超时相应的 SQL 错误码和原因码：
db2pdcfg -catch 911,68 count=1
除了一些字符串值和 SQL 代码之外，db2pdcfg 还接受内部 DB2 错误码。所以，用这种方式可以捕捉很多数据库故障和事件。锁超时事件只是使用 db2pdcfg 和 db2cos 的一个例子。
如果 count 子选项的值为 1，则表明当出现锁超时事件时应该执行 db2cos 脚本。
db2pdcfg 通过以下输出确认错误捕捉的设置：
Error Catch #1 Sqlcode: 0 ReasonCode: 0 ZRC: -2146435004 ECF: 0 Component ID: 0 LockName: Not Set LockType: Not Set Current Count: 0 Max Count: 1 Bitmap: 0x4A1 Action: Error code catch flag enabled Action: Execute sqllib/db2cos callout script Action: Produce stack trace in db2diag.log
db2diag.log 报告中也包括错误捕捉设置。可以使用 db2diag 实用程序（用于检查 db2diag.log 内容的一个有用的实用程序）过滤 db2diag.log 文件，而不必在一个文本编辑器中打开它：
db2diag -g funcname:=pdErrorCatch 2006-12-18-13.37.25.177000+060 I727480H285 LEVEL: Event PID : 4648 TID : 3948 PROC : db2syscs.exe INSTANCE: DB2 NODE : 000 FUNCTION: DB2 UDB, RAS/PD component, pdErrorCatch, probe:30 START : Error catch set for ZRC -2146435004
ZRC -2146435004 是用于锁超时的 DB2 内部错误码。可以通过下面的 db2diag 调用查看这些错误码：
db2diag -rc -2146435004
通过使用 db2pdcfg，数据库引擎现在被配置为每当出现锁超时时调用 db2cos 脚本。db2cos 脚本收集判别锁超时原因所需的所有监视器信息。为此，DBA 必须修改 db2cos 脚本，以便用已知的选项调用 db2pd。可以在下面的子目录中找到 db2cos 脚本：
Windows：DB2 install directory\BIN\db2cos.bat，例如 C:\Program Files\IBM\SQLLIB\BIN\db2cos.bat UNIX/Linux：Instance owner home/sqllib/bin/db2cos
在 Microsoft Windows® 上，默认的 db2cos.bat 脚本看上去如下所示：
setlocal :iterargs if %0. == . goto iterdone if /i %0. == INSTANCE. set INSTANCE=%1 if /i %0. == DATABASE. set DATABASE=%1 if /i %0. == TIMESTAMP. set TIMESTAMP=%1 if /i %0. == APPID. set APPID=%1 if /i %0. == PID. set PID=%1 if /i %0. == TID. set TID=%1 if /i %0. == DBPART. set DBPART=%1 if /i %0. == PROBE. set PROBE=%1 if /i %0. == FUNCTION. set FUNCTION=%1 if /i %0. == REASON. set REASON=%1 if /i %0. == DESCRIPTION. set DESCRIPTION=%1 if /i %0. == DiAGPATH. set DIAGPATH=%1 shift goto iterargs :iterdone if %DATABASE%. == . goto no_database db2pd -db %DATABASE% -inst >> %DIAGPATH%\db2cos%PID%%TID%.%DBPART% goto exit :no_database db2pd -inst >> %DIAGPATH%\db2cos%PID%%TID%.%DBPART% :exit
对于数据库级的事件或故障，默认的 db2cos 脚本用 -db 和 -inst 选项调用 db2pd。DBA 用一个 db2pd 调用替换相应的行，该调用收集锁超时分析所需的监视器数据：
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，以确定锁超时发生的确切时间：
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 : 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 Files\IBM\SQLLIB\DB2 %PID% = process ID = 2968（如 db2diag.log 条目中所示） %TID% = thread ID = 2932（也显示在 db2diag.log 条目中） %DBPART% = database partition = 0（在一个非分区数据库环境中）
那个文件的内容很像本文第一部分中逐步考察的那个 db2pd 监视器输出，DBA 可以通过它来识别锁超时的原因。
捕捉到锁超时后，DBA 可以通过 -catch clear 选项调用 db2pdcfg 来禁用 db2cos 脚本：
db2pdcfg -catch clear All error catch flag settings cleared.
本文演示了如何使用 db2pd 实用程序进行锁等待监视。本文借助一个示例场景展示了 DBA 如何通过检查不同 db2pd 选项的输出来识别并发问题的原因。从 DB2 9 开始，可以将 db2pd 与新的 db2cos 脚本一起使用，以便在出现锁超时事件时捕捉它们。您学习了如何配置出现锁超时事件时 db2cos 脚本的自动调用。本文还介绍了 db2diag 实用程序 —— 这是用于检查 db2diag.log 内容的一个有用的工具。
学习
您可以参考本文在 developerWorks 全球站点上的英文原文。
Sam Poon 撰写的文章 “db2pd 工具 - 用于监控 DB2 实例和数据库的新的 DB2 UDB 工具”（developerWorks，2005 年 4 月）对 db2pd 的监视功能做了概述。
DB2 9 for Linux, UNIX, and Windows 文档中的Monitoring and troubleshooting using db2pd 章节包含了使用 db2pd 进行 DB2 监控的更多使用场景。
除了介绍 DB2 数据并发性的概念之外，教程 “DB2 9 基础（730 考试）认证指南，第 6 部分：数据并发性” 还对 DB2 使用的不同类型的锁作了很好的概述。
在文章 “理解 DB2 通用数据库中的锁定：一个说明示例”（developerWorks，2005 年 11 月）中， Lorysa Bond 介绍了 DB2 锁策略背后的原理。
Werner Schuetz 撰写的文章 “Lock avoidance in DB2 UDB V8”（developerWorks，2005 年 9 月）解释了 DB2 并发性的基础知识，并展示了如何通过设置专用 DB2 寄存器变量影响 DB2 的锁行为。
HTML 格式的完整的 DB2 9 for Linux, UNIX, and Windows 在线文档：DB2 Information Center
DB2 for Linux, UNIX, and Windows 技术支持网站：DB2 Technical Support：在这里可以搜索 APAR，下载修复包，获得 PDF 格式的 DB2 for Linux, UNIX, and Windows 文档，等等。
访问developerWorks 关于 DB2 9 的资源页面，阅读文章和教程，并涉猎其他资料，进一步扩展您的 DB2 技能。
了解DB2 Express-C，这是为社区提供的免费版的 DB2 Express Edition。
浏览技术书店，找到关于这些技术主题和其他技术主题的书籍。
获得产品和技术
下载免费试用版的DB2 Enterprise 9。
现在可以免费使用 DB2。您可以下载DB2 Express-C，这是为社区提供的免费版本的 DB2 Express Edition，它具有与 DB2 Express Edtion 相同的核心数据特性，并为构建和部署应用程序提供了坚实的基础。
下载IBM 试用软件，并获取来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
通过参与developerWorks blog 加入developerWorks 社区。

 

Dirk Fechner 在 IBM Software Group 中担任 IT 服务专家。他的专长领域是分布式平台上 DB2 UDB 的管理和应用程序开发。他拥有 5 年 DB2 UDB 方面的经验，也是一名 IBM 认证的高级 DBA 和 IBM 认证的应用程序开发人员。目前，他在 DaimlerChrysler 为管理员、开发人员和最终用户就各种 DB2 主题提供支持，包括管理任务、应用程序开发以及问题判别