db2数据库出现长事务卡住了，应该怎么查看并分析其具体原因？

在DB2数据库的日常运维与性能调优中，识别并处理长事务是一项至关重要的任务，长事务不仅会占用大量的系统资源，如锁、日志空间和内存，还可能引发连锁反应，导致其他会话长时间等待，严重影响数据库的整体性能和稳定性，所谓“长事务”，通常指那些执行时间远超预期、长时间未提交或回滚，或者持有锁时间过久的事务，本文将系统性地介绍在DB2数据库中查看和诊断长事务的多种方法，从实时监控到历史分析，为数据库管理员（DBA）提供一套完整的排查思路。

利用快照函数与管理视图进行实时诊断

这是DB2中最常用且直接的方法，通过查询系统提供的快照函数或管理视图,可以快速获取当前数据库活动会话的详细信息。

查询应用信息和事务时长

要判断一个事务是否“长”，最核心的指标之一是其持续时间，我们可以通过 SYSIBMADM.APPLICATIONS 管理视图或 SNAP_GET_APPL_INFO 快照函数来获取每个应用程序代理的详细信息,特别是工作单元的开始时间。

-- 使用管理视图查询运行时间超过10分钟的应用
SELECT
    APPL_HANDLE,
    APPL_NAME,
    APPL_ID,
    CLIENT_NNAME,
    UOW_START_TIME,
    CURRENT TIMESTAMP - UOW_START_TIME AS ELAPSED_TIME,
    STMT_TEXT
FROM
    SYSIBMADM.APPLICATIONS
WHERE
    UOW_STATUS = 'UOW Executing'  -- 只关注正在执行的事务
    AND CURRENT TIMESTAMP - UOW_START_TIME > 10 MINUTES;

在上述查询中：

• APPL_HANDLE：应用句柄,是强制结束会话等操作的重要标识。
• APPL_NAME：应用程序名称,帮助定位来源。
• UOW_START_TIME：当前工作单元（事务）的开始时间。
• ELAPSED_TIME：计算出的已运行时间,这是判断事务长短的关键。
• STMT_TEXT：当前正在执行的SQL语句,有助于分析事务为何运行缓慢。

查看锁等待情况

长事务常常是锁等待问题的“罪魁祸首”，当一个事务长时间持锁，其他需要相同锁的事务就会被阻塞，通过 SYSIBMADM.LOCKS_WAITING 视图，可以清晰地看到谁在等待锁,以及谁持有了这个锁。

-- 查看当前所有的锁等待关系
SELECT
    AGENT_ID_HOLDING AS HOLDER_AGENT_ID,
    APPL_NAME_HOLDING AS HOLDER_APPL_NAME,
    AGENT_ID_WAITING AS WAITER_AGENT_ID,
    APPL_NAME_WAITING AS WAITER_APPL_NAME,
    LOCK_MODE,
    OBJECT_TYPE,
    OBJECT_NAME
FROM
    SYSIBMADM.LOCKS_WAITING
ORDER BY
    AGENT_ID_HOLDING;

结合上一步的查询，你可以用 HOLDER_AGENT_ID 或 APPL_HANDLE 关联到 SYSIBMADM.APPLICATIONS 视图,从而确定持有锁的事务已经运行了多久。

使用专门的长时间运行SQL视图

DB2提供了一个非常便捷的管理视图 SYSIBMADM.LONG_RUNNING_SQL，它直接列出了所有执行时间超过 mon_act_sql_history 配置参数设定的阈值的SQL语句。

-- 查看所有长时间运行的SQL
SELECT
    AGENT_ID,
    APPL_NAME,
    STMT_TEXT,
    STMT_START_TIME,
    ELAPSED_TIME_MIN,
    UOW_LOG_USED
FROM
    SYSIBMADM.LONG_RUNNING_SQL
ORDER BY
    ELAPSED_TIME_MIN DESC;

这个视图是定位性能瓶颈的利器，ELAPSED_TIME_MIN 直接告诉你SQL已经运行了多少分钟。

使用db2top命令行工具

db2top 是一个功能强大的实时监控工具，以交互式界面的形式展示了数据库的动态性能指标,非常适合快速现场诊断。

1. 启动db2top：在命令行中执行 db2top -d <数据库名>。
2. 查看应用/会话信息：进入主界面后，按 u 键进入 Sessions 选项，这里会列出所有活动的应用连接，并显示 UOW Time（事务运行时间）、CPU%、I/O 等关键信息，你可以按 UOW Time 排序,快速定位运行时间最长的会话。
3. 查看锁信息：在主界面按 l 键进入 Locks 选项，这里会显示当前所有锁的情况，包括锁的模式、对象以及持有者和等待者，通过 b (Blocked) 或 w (Waiting) 标识,可以很容易的发现锁等待链。

db2top 的优势在于其直观性和实时性,无需编写复杂的SQL语句即可获得丰富的信息。

借助db2pd工具进行深度诊断

当需要从更底层、更详细的角度分析问题时，db2pd（database performance doctor）是不二之选，它直接从数据库的内存中抓取信息，不受锁的限制,即使在数据库响应缓慢时也能正常使用。

# 查看特定数据库的锁、事务和应用信息
db2pd -d <数据库名> -db cfg -locks -transactions -apps

• -locks：详细的锁列表，包括表锁、行锁及其持有者。
• -transactions：事务列表，显示事务状态（如 UOW Executing, UOW Waiting）、日志使用情况等。
• -apps：应用信息，包括应用句柄、状态等。

通过综合分析这几个部分的输出，可以构建出一个非常精确的锁等待和事务状态图,特别适用于解决复杂的死锁或性能问题。

通过事件监视器进行历史分析

三种方法主要用于实时诊断，如果要分析过去某个时间段内发生过的长事务,就需要使用事件监视器。

1. 创建并激活事件监视器：可以创建一个专门用于记录语句或事务的事件监视器。

   CREATE EVENT MONITOR long_act_mon FOR STATEMENTS, TRANSACTIONS
   WRITE TO UNFORMATTED EVENT TABLE (
       TABLE my_act_tab,
       CONTROL TABLE my_act_ctrl
   );
   ACTIVATE EVENT MONITOR long_act_mon;

2. 分析事件表：事件监视器会将捕获到的事件写入到指定的表中，当问题发生后，可以通过查询这些表来进行分析。

   -- 从事件表中查询历史长事务
   SELECT
       AGENT_ID,
       APPL_NAME,
       UOW_START_TIME,
       UOW_STOP_TIME,
       UOW_ELAPSED_TIME_MS / 1000 AS ELAPSED_TIME_SEC
   FROM
       TABLE (SYSPROC.READ_EVENT_TABLE('MY_ACT_TAB', 'MY_ACT_CTRL')) AS T
   WHERE
       EVENT_TYPE = 'TRANSACTION'
       AND UOW_ELAPSED_TIME_MS > 300000 -- 5分钟
   ORDER BY
       UOW_ELAPSED_TIME_MS DESC;

事件监视器是进行性能审计和根因分析的有力工具，但需要注意它会带来一定的性能开销,应在必要时使用。

---

方法对比小编总结

方法名称	使用场景	复杂度	优点	缺点
快照/管理视图	实时诊断	低	SQL查询灵活，易于集成到脚本中	信息可能受锁影响，在高负载时查询本身可能慢
db2top	实时快速诊断	中	界面直观，信息丰富，实时性强	需要服务器端访问，信息不够持久化
db2pd	深度/紧急诊断	高	直接读取内存，信息最底层、最准确	输出格式为文本，不易解析，需要专业知识
事件监视器	历史分析	高	可回溯分析，适合性能调优和审计	有性能开销，配置和数据分析相对复杂

---

相关问答FAQs

问1：我找到了一个造成严重阻塞的长事务，应该如何处理？

答： 处理长事务需要谨慎,建议按以下步骤进行：

1. 分析而非立即终止：通过上述方法确定长事务的应用来源（APPL_NAME）、执行的SQL（STMT_TEXT）以及运行时长，判断是SQL性能问题（如缺少索引）还是应用逻辑问题（如忘记提交）。
2. 尝试沟通：如果可能，联系应用负责人或最终用户,确认该事务是否可以安全终止。
3. 强制执行：如果沟通无效且该事务已严重影响业务，作为最后手段，可以考虑强制结束该应用，使用命令 FORCE APPLICATION (<appl_handle>)，强制执行会导致该事务立即回滚，这可能会消耗大量日志和I/O资源，并可能造成应用数据不一致,务必在评估风险后操作。

问2：如何从根源上预防长事务的产生？

答： 预防远胜于治疗,可以从以下几个方面着手：

1. 优化应用设计：遵循“事务要短，锁粒度要小”的原则，确保事务只包含必要的操作，尽快提交或回滚,避免在事务中进行用户交互或长时间等待外部资源。
2. SQL性能调优：对事务中的高频或复杂SQL进行优化，确保其执行计划最优，定期执行 RUNSTATS 更新统计信息,为优化器提供准确的数据。
3. 批量操作合理分批：对于大批量数据操作（如ETL），应设置合理的批次大小，每处理一批数据就提交一次,避免单个巨型事务。
4. 配置数据库参数：合理设置 LOCKTIMEOUT 参数，当锁等待超过设定时间时自动回滚事务，避免无限等待，配置 MAXLOGSIZE 和 MAXLOG 等日志相关参数,防止日志空间被单一事务耗尽。