本文阐述了开发人员和测试人员如何确定 DB2 for z/OS 环境下复杂 Web 应用程序中的死锁原因。简介在任何数据库环境中，死锁检测对于应用程序并发性都是很重要的。就像其他应用程序一样，在复杂 Web 环境中也需要能够确定任何死锁的起因。本文解释了如何配置 DB2 for os/390 的死锁跟踪设置，以启用死锁分析。先阐述了如何指定相关的 DB2 for z/OS 跟踪以获取足够信息，然后说明如何分析这些跟踪报告，并指出引起 DB2 for z/OS 环境中运行的复杂 Web 应用程序出现死锁的不良 SQL 语句。本文假定读者熟悉基本的 z/OS 操作。使用 DB2 Performance Monitor 来配置跟踪Locking 跟踪若要启用 Locking 跟踪，首先打开 IBM DB2 Performance Monitor 应用程序。然后执行下面步骤：配置 Collect Task A 以收集死锁跟踪。设置 Trigger by 4=Immediate Start 以立即激活任务。选择 Locking, Data Type, IFICD, Requesting Location, Plan name and Authid，然后按 Enter。图 1. 配置 Collect Task A
107Data set open/close information
172Deadlock在 Trace Qualification 面板中，填入 DB 用户名（在本例中为 TUSER03）和 DB 模式（在本例中为 TGUSER03），然后按 Enter。图 2. Trace qualification 面板
20Lock summary
53Describe, SQL commit/rollback or error before SQL analyzed
58End of SQL statement execution
59Start of FETCH
60start of SELECT
61Start of INSERT, UPDATE or DELETE
63SQL statement to be parsed
64start of PREPARE
65start of OPEN CURSOR for static or dynamic SQL
66Start of CLOSE CURSOR for static or dynamic SQL
68Start of ROLLBACK
69End of ROLLBACK
70Start of COMMIT phase 2
71End of COMMIT phase 2
88start of synchronous request (commit phase 1)
89End of synchronous request (commit phase 1)
105DBID/OBID for database and tablespace translation在 Trace Qualification 面板中，填入 DB 用户名（例如，TUSER03）和 DB 模式（例如，TGUSER03），然后按 Enter。在 Trigger Immediately 面板中，填入 DB2 跟踪数据的输出数据集（例如，TGUSER03.DB2PM.TRACE02）。设置 Disposition 为 Overwrite。注重：可以使用其他方法来配置 DB2 跟踪停止触发器（例如，经过一段时间后）。按 Enter 完成 SQL Activity 配置。在 Web 应用程序运行期间，激活 Collect Task B 来收集 SQL 语句。分析跟踪报告以确定不良 SQL 语句Web 应用程序中 DB2 锁的原理通常 Web 应用程序有页锁和行锁。根据创建数据库所使用的数据定义语言 (DDL) 模式文件，可以确定正在使用的锁类型。行锁有三种模式：S(Share)、U(Update) 和 X(Exclusive)。要尽量避免的锁影响是挂起、超时和死锁。当两个或两个以上应用程序进程均持有对资源（该资源是其他进程所需，且没有该资源时进程无法继续进行）的锁时，会发生死锁。下面是关于发生死锁情况的具体解释：JobOne 和 JobTwo 是两个事务。JobOne 访问表 M，并持有页 B 的 X (exclusive) 锁，包含记录 000300。JobTwo 访问表 N，并持有页 A 的 X (exclusive) 锁，包含记录 000010。JobOne 请求表 N 页 A 的锁，同时仍持有表 M 页 B 的锁。因为 JobTwo 持有页 A 的 X 锁，所以作业被挂起。JobTwo 请求表 M 页 B 的锁，同时仍持有表 N 页 A 的锁。因为 JobOne 持有页 B 的 X 锁，所以作业被挂起。这种情况就是死锁。为了改善应用程序的并发性，您需要找到引起死锁的 SQL 语句。然后，优化 SQL 语句以消除死锁。根据死锁报告来分析锁信息作为例子，我们假定当多个顾客同时登录并注册一个商店时发生死锁。您已经得到死锁跟踪报告和 SQL 语句报告。首先，您应检查死锁跟踪报告（在本文中为 TGUSER03.DB2PM.LOCKS）。下面是跟踪报告中一些要害参数的说明，有助于理解该进程：图 4. 跟踪参数
LUW 实例
持有的资源（X 锁）
请求的资源（S 锁）
死锁时间表
0CC544053119
SW03DB1.USERS.X'00004E'.X'2B'
SW03DB1.USERS.X'00004C'.X'2B'
06:30:09.41044991
0E26A4053107
SW03DB1.USERS.X'00004C'.X'2B'
SW03DB1.USERS.X'00004E'.X'2B'
06:30:09.41044991
根据 SQL 活动报告来分析 SQL 信息打印 SQL ACTIVITY 跟踪（在本文中为 TGUSER03.DB2PM.SQL），使用死锁所涉及的 LUW INSTANCE 数量(0CC544053119 和 0E26A4053107）进行过滤。可以发现最后一次 commit 操作应正好在死锁出现 (06:30:09.41044991) 前完成。接下来，搜索仅在完成最后一次 commit 操作后执行的 SQL 语句。COMMIT processing in SQL ACTIVITY trace for INSTANCE 0CC544053119
COMMIT RECEIVED06:28:50.72
COMMIT RECEIVED06:28:50.85
COMMIT RECEIVED06:28:50.97
COMMIT RECEIVED06:28:51.04the latest commit before the deadlock occurred.
COMMIT RECEIVED06:30:09.61
COMMIT RECEIVED06:30:09.64
COMMIT RECEIVED06:30:09.73
COMMIT RECEIVED06:30:09.77
COMMIT RECEIVED06:30:09.80因此，应该研究那些访问过 SW03DB1.USERS 且在 06:28:51.04 到 06:30:09.41044991 之间执行的 SQL 语句。如图 7 所示。图 7. SQL 报告
COMMIT RECEIVED 06:28:50.65the latest commit before the deadlock occurred.
COMMIT RECEIVED 06:30:49.67然后，研究那些访问过 SW03DB1.USERS 且在 06:28:50.65 到 06:30:09.41044991 之间执行的 SQL 语句。如图 8 所示。图 8. SQL 报告
