(转)Db2 数据库常见堵塞问题分析和处理

原文：https://www.ibm.com/developerworks/cn/analytics/library/ba-lo-db2-common-blocking-problem-analyze/index.html

Db2 数据库堵塞怎么办

作为一个数据库管理员，工作中经常会遇到的一个问题：当数据库出现故障的情况下，如何快速定位问题和找到解决方案。尤其是在运维非常重要系统的时候，解决问题恢复服务是分秒必争。Db2 作为广泛使用的商业数据库，内部提供了众多方法论和诊断工具等来协助分析问题。然而当问题真正发生的时候，数据库管理员还是会手忙脚乱，不知道从何处下手。如果着手分析的方向发生了错误，时间更是浪费严重，问题得不到及时解决，甚至有可能采取了错误的措施，导致更严重的后果。

导致数据库堵塞原因有很多，即便是现在总结，也仅仅是总结曾经遇到过的情况。即便是曾经遇到的问题重复发生的时候，快速找到源头并处理也是很大的挑战。这个时候脑子里想着方法论，手上敲着各种诊断工具的命令，从输出的结果再继续分析处理。整个过程即便是非常有经验的数据库管理员也需要很多操作时间。如果可以针对常见的堵塞问题，开发出一个自动分析的工具，直接展示堵塞原因和处理语句，就能够大大加快处理的速度。这也是一直以来数据库管理员亟需的工具。然而因为导致数据库堵塞原因的多样性和未知性，写这样一个工具并不容易，所以市场上并没有这样的成熟工具。

退而求其次，仅仅针对常见的堵塞问题，是可以开发出这样的一键检查处理工具的。所以我开发了一个简单的 python 脚本，帮助分析日常工作中的遇到的数据库问题。后续也需要慢慢加强和改进。最重要的是，写这个文章是为了总结几种 Db2 数据库常见的堵塞问题并提供解决方案。

开发这个工具的时候，我联想到在以前遇到过数据库堵塞问题的时候，数据库甚至都没有办法连接，新请求也会被堵塞住。db2top 等命令完全出不来结果。只有 db2pd 这样的工具能够使用。db2pd 工具是从内存直接获取信息，不需要连接数据库，属于轻量级的诊断工具。所以在数据库发生堵塞，数据库无法连接的情况下，db2pd 是最好的选择。

DB2 数据库堵塞怎么办？首先是快速定位原因，使用 db2pd 将常见的堵塞现象分析一遍。如果定位到是曾经碰到的问题，那就比较好办了，赶紧实行对应的解决方案。如果不是常见的问题，尽量收集足够多的信息，例如 stack 等，然后重启实例恢复数据库，但是这样可能堵塞问题还是会重现，不能根本解决问题。

Db2 数据库常见堵塞问题

Db2 数据库发生性能缓慢或者堵塞的最常见现象是数据库活动会话激增，数据库相关命令和语句运行缓慢。导致性能缓慢的原因有很多，最常见的可能是出现锁问题。一个长 sql 堵塞其他相关 sql，导致短时间并发 sql 变多，系统变慢。也有可能是出现了大 sql，耗尽系统资源等。如下图所示，我归纳列举了一些常见的堵塞原因，整理了相关问题解决的方法。

图 1. Db2 常见堵塞问题分析

图中所列的这些问题都可以通过 db2pd 工具获取信息来分析。我也在一键检查分析工具里面包含了这些场景。

锁链分析和处理

Db2 的锁机制与其他数据库差异很大，锁问题也是在数据库运维中重点关注的对象。锁是用来控制事务的一致性和并发性的。Db2 的隔离级别和其他数据库差不多，都是解决脏读，幻读，不可重复读等问题。然而不同于其他数据库，Db2 的锁是存放在内存里的。数据库的 locklist 参数控制这个内存的大小。如果出现某个实务需要加的锁特别多，可能会导致这个内存里放不下，触发锁升级。锁升级更容易引起堵塞。

发现锁堵塞

一个正常运行的数据库突然出现锁问题通常有两种情况： 一种是运行了不常运行的 SQL 事务，堵塞了正常的交易。一种是正常的交易事务突然性能有问题，例如查询计划改变。不管是哪种情况，最紧要的是将源头找出来。db2top 工具有一个非常好用的功能，就是查看锁链的信息。

清单 1. db2top 查看锁链

在这个输出里面，1546 这个应用是锁的持有者，其他都是等待者。下一步就是分析 1546 在执行什么语句，是否需要杀，是否需要优化。

然而对于已经堵塞的 Db2 数据库，db2top 可能根本打不开。这个时候就需要 db2pd 工具来查看锁等待的信息。

清单 2. db2pd 查看锁等待

在这个 db2pd 的输出里面，第八列 Sts 就是持有者（G）和等待者（W）。第四列 lockname 是对应的锁。需要综合这两个信息，才能知道应用的等待关系。这里分析锁等待关系并不是非常直观。所以我在开发的工具里结合 lockname 和锁状态信息组织出锁链关系，然后展示出来。

分析锁问题

基于上述信息，找到锁的持有者源头，现在还需要知道持有者在运行什么语句。这个可以通过 db2pd 的 application 选项和 dynamic 选项综合分析出当前正在执行和上次执行的语句。

清单 3. db2pd 查看 application

在 db2pd 工具的 application 输出里面，C-AnchID 和 C-StmtUID 结合起来指向当前正在运行的语句。L-AnchID 和 L-StmtUID 结合起来指向上一次执行的语句。要获得详细的语句，需要从 dynamic cache 里找到。图中 C-AnchID 和 C-StmtUID 都是 0，也就是当前应用没有执行任何语句。而 L-AnchID 和 L-StmtUID 是 341 和 2，上一次执行的语句是可以获取到的。

清单 4. db2pd 查看动态语句

基于 L-AnchID 为 341 去查 dynamic cache，可以看到 StmtUID 为 2 的 sql 语句是"select * from t with rr"。至此就得到了锁的持有者正在运行的语句或者最后运行的语句是什么。这样就可以和开发一起分析这个问题是什么原因导致的。

处理锁问题

通常异常出现锁问题的原因分两种：

• 不常见的 SQL：当前 SQL 不是业务常用 SQL，例如新上线的功能，管理节点发起的维护 SQL，或者个人后台发起的 SQL 等。因为测试不充分，没有评估好对生产业务的影响。这种情况下一般选择先杀掉，并且控制不要再次发起，等优化完再上线。
• 常见 SQL 突然变慢：例如执行计划发生变化，导致 SQL 变慢，从而促发了锁竞争的问题。这种情况仅仅杀 SQL 可能是不管用的，因为 SQL 还会被调用起来。这时需要立刻获取 SQL 的查询计划，抓紧时间调优。例如运行 runstats，创建必要的索引等方式。

我在 Db2 堵塞一键检查工具里面对上述操作进行了自动化分析和处理。

清单 5. 一键检查工具分析锁问题

工具在分析锁问题的时候，首先展示锁链并排序，然后找到所有锁链中锁持有者执行的 SQL 语句，并将需要快速杀应用的语句打印出来，便于快速决策是否调用。

latch 链分析和处理

Db2 的 latch 是一个教科书里没有详细阐述也无法详细枚举所有 latch 种类的机制。Latch 简单来说就是线程锁。它和 Db2 的锁不一样但是堵塞时的现象差不多，都是一个线程获取到了 latch，堵塞了其他需要这个 latch 的线程。Latch 促发的问题可能还要严重。Lock 通过杀掉持有者的 apphdl 还可以释放，Latch 的持有者可能并不是应用，可能是 Db2 的其他内部线程，是没有开放接口去杀的。这种情况下只有等待或者重启实例。

latch 问题可能是数据库管理员最头疼的问题。因为通常这种问题牵涉的是 Db2 开发的内部机制，属于未公开的信息。基本上这个时候能做的只是想办法解开 latch，收集信息给 IBM 支持团队分析原因。

查看 latch 堵塞

处理这类问题首先是监控是否发生了 latch 等待：

清单 6. db2pd 查看 latch 等待

图中的输出信息分两个主要部分。第一部分是有持有者的 latch 信息，包含有等待的和没等待的。没有等待者的持有者是不需要关心的。第二部分是找不到持有者但是有等待者的 latch 信息。相对第一部分，这个是因为持有者在内部开发的代码里没有显示给监控，并不是真的没有持有者。解读下这个输出里面的内容：

• Address：latch 地址，唯一定位一个 latch 对象。
• Holder：latch 的持有者。这是个 EDUID。
• Waiter：latch 的等待者。这是个 EDUID。
• Filename：获取这个 latch 的源文件名。
• LOC：源文件里的代码位置。
• LatchType：latch 名称。
• HoldCount：持有数量。

上面这个例子包含三种场景：

1. latch 地址为 0x0780000004F00478 的持有者是 1553，等待者是 0 也就是没有等待者。这是一个正常的现象，不需要去关注。
2. latch 地址为 0x0A00050000069D20 的持有者是 33105，等待者有 589675 和 528805。这是一个典型的堵塞现象。33105 堵塞了 589675 和 528805。这个 latch 的名称是 SQLO_LT_SQLP_DBCB__add_logspace_sem。
3. latch 地址为 0x0A0005059594A800 和 0x0A00050225DAA938 没有显示持有者（显示持有者的代价太高，所以 Db2 内部屏蔽了），但是分别有等待者 529319 和 415209。这个 latch 的名称是 SQLO_LT_SQLB_BPD__bpdLatch_SX。

Latch 的等待信息是瞬间抓取的，如果想要确定是否存在堵塞现象，需要多抓一次 latch 信息来确认。在确认了 latch 堵塞问题的情况下，需要抓取 stack 来获取详细信息给 IBM 的支持开 case。Latch 问题的处理里面 stack 是关键信息。发生竞争的 latch 持有者和等待者都需要抓取 stack。抓取 stack 的语句是：db2pd -stack <eduid>。 这里的 eduid 输入就是 latch 选项输出里面的 Holder 和 Waiter。

分析 latch 堵塞对象

如果是有持有者的堵塞现象，可以检查持有者是什么 EDU，是否对应到 application，然后确定能否通过解决持有者的方式释放这个堵塞问题。

清单 7. db2pd 查看 edu 等待

通过 db2pd 工具能够查看 EDUID 对应的 EDU Name 是什么。如果 EDU Name 是 db2agent，那么就能对应到一个 application。这个时候查看对应数据库的 applications 输出，就找到 CoorEDUID 对应的 AppHandl 了。

清单 8. db2pd 查看 application

找到了 AppHandl，就可以查看到对应的 SQL 语句是什么，知道这个应用在做什么。方法分析锁问题的时候找 SQL 一样。最后尝试"db2 force application (<AppHandl>)"，运气好的话这个堵塞问题可能就暂时解决了。

处理 latch 堵塞问题

获取到 latch 名称后，首先去 IBM 网站查找这个 latch 的关键词，看看有没有已知的问题现象一致，有没有解决办法。最后一定要开 CASE 找 IBM 官方支持，找到真正原因，避免再出现这样的问题。我在一键检查工具里面按照这个思路处理 latch 问题。

清单 9. 一键检查工具分析 latch 问题

这个工具会对每个出现堵塞的 latch 地址展开 latch 链，然后对相关 eduid 收集 stack，最后尝试找到这些 eduid 对应的 apphandl 和 sql 语句。如果持有者对应到 apphandl，那么也把处理的 force 语句打印出来。

查看当前运行时间长的 SQL 语句

Db2 出现运行缓慢如果不是因为锁或者 latch 的等待问题。这时就需要看看当前哪些 SQL 运行的时间比较长。我会挑选 10 条运行时间最长的 SQL 来分析。

清单 10. 查看 activestatements

这个输出里面需要关注的是 StartTime，按照这个排序就可以找到运行时间最长的语句了。和分析锁堵塞问题里的方法一样。这里的 AnchID 和 StmtUID 可以在 dynamic cache 里面定位到唯一的 SQL 语句。这个在一键检查工具里面是自动收集展示的。

清单 11. 一键检查工具查看 TOP SQL

这个工具基于执行时间排序，只抓取前 10 的 SQL 语句。获得这些信息后就可以分析有没有异常。

查看热表和相关 SQL 语句

Db2 运行缓慢不可忽视的诱因之一就是存在热点数据。通常热点数据会伴随锁等待和 latch 等待等现象，但不是完全堵塞的状态。现象就是热点表相关的 SQL 会比正常情况下慢很多，从而导致整个数据库运行缓慢。

获取热点表

当数据库出现缓慢的时候，如果想要从热点数据的角度去分析问题，找到对应的表，然后再找到对应的热点语句，就可以分析是否存在问题，是否需要优化。db2top 首页键入 T 可以进入 Tables 的监控界面。在这个界面里能看到 Delta RowsRead 和 Delta RowsWritten 等信息，从而获取当前热点表信息。

清单 12. db2top 查看热点表

db2top 最强的地方就是能够自动获取两次捕获信息之间的差异并计算出 Delta 值展示出来。其<