DB2查询锁表时如何定位阻塞会话？

Question

在DB2数据库运维中，当出现锁等待或性能下降时，如何快速定位导致锁表的阻塞会话成为一个关键问题。常见的技术问题是：**如何通过系统监控视图查询当前活跃锁及其阻塞关系，准确识别出持有锁的源头会话（blocking session）以及被阻塞的等待会话（waiting session）？** 具体表现为：应用连接挂起、SQL执行超时、事务长时间不提交等现象。此时需借助`SYSIBMADM.SNAPLOCK`、`SYSIBMADM.LOCKWAITS`等快照视图，结合`AGENT_ID`、`BLOCKING_AGENT`等字段分析锁持有与等待链。但实际操作中常因视图数据理解不清或关联信息缺失，导致无法迅速锁定根因会话。掌握正确的查询语句与字段含义，是高效排查DB2锁阻塞问题的核心技能。

Answer 1

一、DB2锁等待问题的背景与核心挑战

在高并发OLTP系统中，DB2数据库常因事务隔离级别设置不当、长事务未提交或索引缺失等问题引发锁竞争。当多个应用会话同时访问相同数据页时，若某会话持有排他锁（X锁），其他会话尝试获取该资源的共享或排他锁时将进入等待状态。

典型现象包括：

• 前端应用连接挂起，长时间无响应
• SQL执行超时报错（如SQL0911，-911）
• 事务日志持续增长，回滚时间变长
• 监控平台显示锁等待数突增

此时需快速定位阻塞源头——即“根因会话”（Blocking Session），而非仅查看被阻塞者。

二、关键系统视图解析：SNAPLOCK 与 LOCKWAITS

DB2提供两类核心快照视图用于实时分析锁状态：

视图名称	用途说明	关键字段
SYSIBMADM.SNAPLOCK	展示当前所有活跃锁信息	AGENT_ID, TABNAME, LOCK_MODE, LOCK_OBJECT_TYPE
SYSIBMADM.LOCKWAITS	专用于显示锁等待链	WAITING_AGENT_ID, BLOCKING_AGENT_ID, TIMEOUT
SYSIBMADM.SNAPAPPL	获取会话上下文信息	AGENT_ID, APPL_NAME, AUTHID, EXECUTING_SQL
SYSIBMADM.SNAPTAB	表级统计辅助分析	DATA_PARTITION_ID, ROWS_READ, OVERFLOW_ACCESSES

三、深入理解 LOCKWAITS 视图中的阻塞关系链

通过以下查询可直接提取当前存在的锁等待对：

SELECT 
    WAITING_AGENT_ID,
    BLOCKING_AGENT_ID,
    WAIT_START_TIME,
    SUBSTR(WAITING_APPLHANDLE,1,8) AS WAITER_HANDLE,
    SUBSTR(BLOCKING_APPLHANDLE,1,8) AS BLOCKER_HANDLE,
    LOCK_OBJECT_TYPE,
    TABSCHEMA,
    TABNAME
FROM SYSIBMADM.LOCKWAITS
ORDER BY WAIT_START_TIME DESC;
    

输出示例包含10行以上真实场景模拟数据：

WAITING_AGENT_ID	BLOCKING_AGENT_ID	WAIT_START_TIME	WAITER_HANDLE	BLOCKER_HANDLE	LOCK_OBJECT_TYPE	TABSCHEMA	TABNAME
12345	67890	2025-04-05 10:23:12	abc12345	def67890	ROW	SALES	ORDERS
12346	67890	2025-04-05 10:23:13	abc12346	def67890	ROW	SALES	ORDERS
12347	67890	2025-04-05 10:23:14	abc12347	def67890	ROW	SALES	ORDERS
12348	67890	2025-04-05 10:23:15	abc12348	def67890	ROW	SALES	ORDERS
12349	67890	2025-04-05 10:23:16	abc12349	def67890	ROW	SALES	ORDERS
12350	67890	2025-04-05 10:23:17	abc12350	def67890	ROW	SALES	ORDERS
12351	67890	2025-04-05 10:23:18	abc12351	def67890	ROW	SALES	ORDERS
12352	67890	2025-04-05 10:23:19	abc12352	def67890	ROW	SALES	ORDERS
12353	67890	2025-04-05 10:23:20	abc12353	def67890	ROW	SALES	ORDERS
12354	67890	2025-04-05 10:23:21	abc12354	def67890	ROW	SALES	ORDERS

四、构建完整阻塞链：从等待会话追溯到根因持有者

单一LOCKWAITS视图可能只反映一级阻塞，但实际环境中可能存在多层嵌套阻塞。使用递归CTE可构建完整的阻塞拓扑结构：

WITH BLOCKING_CHAIN (LEVEL, WAITING_AGENT, BLOCKING_AGENT, WAIT_START, PATH) AS (
    SELECT 
        1 AS LEVEL,
        WAITING_AGENT_ID,
        BLOCKING_AGENT_ID,
        WAIT_START_TIME,
        CAST('.' || RTRIM(CHAR(WAITING_AGENT_ID)) || '.' AS VARCHAR(1024))
    FROM SYSIBMADM.LOCKWAITS
    WHERE BLOCKING_AGENT_ID NOT IN (SELECT WAITING_AGENT_ID FROM SYSIBMADM.LOCKWAITS)
    
    UNION ALL
    
    SELECT 
        BC.LEVEL + 1,
        L.WAITING_AGENT_ID,
        L.BLOCKING_AGENT_ID,
        L.WAIT_START_TIME,
        '.' || RTRIM(CHAR(L.WAITING_AGENT_ID)) || BC.PATH
    FROM SYSIBMADM.LOCKWAITS L
    INNER JOIN BLOCKING_CHAIN BC ON L.BLOCKING_AGENT_ID = BC.WAITING_AGENT
    WHERE BC.LEVEL < 10
)
SELECT * FROM BLOCKING_CHAIN ORDER BY LEVEL DESC;
    

五、关联会话上下文：识别阻塞源头的应用行为

仅知道AGENT_ID不足以采取行动，必须结合SNAPAPPL获取执行语句和客户端信息：

SELECT 
    A.AGENT_ID,
    A.APPL_NAME,
    A.AUTHID,
    A.CLIENT_PID,
    A.COORD_MEMBER,
    S.EXECUTING_SQL
FROM SYSIBMADM.SNAPAPPL A
JOIN SYSIBMADM.SNAPDYN_S SQLS ON A.AGENT_ID = SQLS.AGENT_ID
WHERE A.AGENT_ID IN (SELECT BLOCKING_AGENT_ID FROM SYSIBMADM.LOCKWAITS);
    

此查询能揭示阻塞会话正在执行的SQL文本，帮助判断是否为批量更新、缺失索引扫描或未提交事务。

六、可视化阻塞拓扑：使用Mermaid绘制等待链

将查询结果转化为图形化表示，便于团队沟通：

graph TD
    A[Agent 67890
UPDATE SALES.ORDERS] --> B[Agent 12345
SELECT FOR UPDATE]
    A --> C[Agent 12346
INSERT INTO ITEMS]
    A --> D[Agent 12347
DELETE FROM LOGS]
    A --> E[Agent 12348
UPDATE CUSTOMERS]
    B --> F[Agent 12349
Blocked Query]
    C --> G[Agent 12350
Waiting Insert]
    D --> H[Agent 12351
Pending Delete]
    E --> I[Agent 12352
Locked Read]
    

该图清晰展示了以Agent 67890为根节点的阻塞树，其长期持有锁导致下游多个会话连锁等待。