您现在的位置是：网站首页> 编程资料编程资料
Db2数据库中常见的堵塞问题分析与处理方法_DB2_
2023-05-27
423人已围观
简介 Db2数据库中常见的堵塞问题分析与处理方法_DB2_
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 查看锁链
[\]16:01:41,refresh=0secs(0.008) Locks AIX,member=[4/4],DB2GDPC:CHGMDB [d=Y,a=N,e=N,p=ALL] [qp=off] +---------------------------------------------------------------------------------+ | | | Blocker->Blocked Agent Chain | | --------------------------------------------------------------------------- | | 1546->64481->1309 | | | | | | | | | | | | | | | | | | | | | | | | Press any key to resume... | +---------------------------------------------------------------------------------+ Quit: q, Help: h Lock=49 (Entries=49), L: Lock Chain db2top 2
在这个输出里面，1546 这个应用是锁的持有者，其他都是等待者。下一步就是分析 1546 在执行什么语句，是否需要杀，是否需要优化。
然而对于已经堵塞的 Db2 数据库，db2top 可能根本打不开。这个时候就需要 db2pd 工具来查看锁等待的信息。
清单 2. db2pd 查看锁等待
AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -wlocks ksh: There is not enough space in the file system. Database Member 0 -- Database CHGMDB -- Active -- Up 19 days 01:18:29 -- Date2018-02-27- 16.52.48.487758 Locks being waited on : AppHandl [nod-index] TranHdl Lockname Type Mode Conv Sts CoorEDU AppName AuthID AppID 1546 [000-01546] 39 00030418000000000000000452 RowLock ..X G 176565 db2bp DB2GDPC *N0.db2gdpc.180430224639 1309 [000-01309] 40 00030418000000000000000452 RowLock ..X W 323302 db2bp DB2GDPC *N0.db2gdpc.180430224640 1546 [000-01546] 39 00030418000000000000000054 TableLock .IX G 176565 db2bp DB2GDPC *N0.db2gdpc.180430224639 1309 [000-01309] 40 00030418000000000000000054 TableLock .IX G 323302 db2bp DB2GDPC *N0.db2gdpc.180430224640 64481 [000-64481] 3 00030418000000000000000054 TableLock ..S W 394879 db2bp DB2GDPC *N0.db2gdpc.180430224637
在这个 db2pd 的输出里面，第八列 Sts 就是持有者（G）和等待者（W）。第四列 lockname 是对应的锁。需要综合这两个信息，才能知道应用的等待关系。这里分析锁等待关系并不是非常直观。所以我在开发的工具里结合 lockname 和锁状态信息组织出锁链关系，然后展示出来。
分析锁问题
基于上述信息，找到锁的持有者源头，现在还需要知道持有者在运行什么语句。这个可以通过 db2pd 的 application 选项和 dynamic 选项综合分析出当前正在执行和上次执行的语句。
清单 3. db2pd 查看 application
AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -application 1546 Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 18:31:55 -- Date 2018-03-01- 10.06.14.595025 Applications: Address AppHandl [nod-index] NumAgents CoorEDUID Status C- AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID CollectActData CollectActPartition CollectSectionActuals 0x0A00020042CA0080 1546 [000-1546] 1 147263 UOW-Waiting 0 0 341 2 *N0.db2gdpc.180504025324 1 37352 N C N External Connection Attributes Address AppHandl [nod-index] ClientIPAddress EncryptionLvl SystemAuthID 0x0A00020042CA0080 1546 [000-1546] n/a None DB2GDPC Trusted Connection Attributes Address AppHandl [nod-index] TrustedContext ConnTrustType RoleInherited 0x0A00020042CA0080 1546 [000-1546] n/a non trusted n/a Autonomous Routine Connections Address AppHandl [nod-index] Status Autonomous Routine Handl [nod- index] Status Anonymous Block Connections Address AppHandl [nod-index] Status Anonymous Block Handl [nod-index] Status
在 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 查看动态语句
AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -dynamic anch=341 Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 19:16:16 -- Date 2018-03-01- 10.50.35.125266 Dynamic Cache: Current Memory Used 1700359 Total Heap Size 130191196 Cache Overflow Flag 0 Number of References 83506 Number of Statement Inserts 74444 Number of Statement Deletes 74408 Number of Variation Inserts 48 Number of Statements 36 Dynamic SQL Statements: Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text 0x0A0005024E0EE9A0 341 2 1 1 3 3 select * from t with rr Dynamic SQL Environments: Address AnchID StmtUID EnvID Iso QOpt Blk 0x0A0005024E0EE520 341 2 2 CS 5 B Dynamic SQL Variations: Address AnchID StmtUID EnvID VarID NumRef Typ Lockname Val Insert Time Sect Size Num Copies 0x0A0005024E0BEE60 341 2 2 1 2 6 000000020000000200012AA0D6 Y 2018-03-01-09.06.10.891027 6056 0
基于 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. 一键检查工具分析锁问题
AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb lock ############################################################################### # Lock Analyze # ############################################################################### #The lock chains are: ['15412', '15657'] ['15412', '19008'] #The root lock holders are: ['15412'] #The stmt for applicaiton 15412 is: The current stmt is:NULL . The last stmt is: select * from t with rr . #You can force the holders by: db2 "force application (15412) "
工具在分析锁问题的时候，首先展示锁链并排序，然后找到所有锁链中锁持有者执行的 SQL 语句，并将需要快速杀应用的语句打印出来，便于快速决策是否调用。
latch 链分析和处理
Db2 的 latch 是一个教科书里没有详细阐述也无法详细枚举所有 latch 种类的机制。Latch 简单来说就是线程锁。它和 Db2 的锁不一样但是堵塞时的现象差不多，都是一个线程获取到了 latch，堵塞了其他需要这个 latch 的线程。Latch 促发的问题可能还要严重。Lock 通过杀掉持有者的 apphdl 还可以释放，Latch 的持有者可能并不是应用，可能是 Db2 的其他内部线程，是没有开放接口去杀的。这种情况下只有等待或者重启实例。
latch 问题可能是数据库管理员最头疼的问题。因为通常这种问题牵涉的是 Db2 开发的内部机制，属于未公开的信息。基本上这个时候能做的只是想办法解开 latch，收集信息给 IBM 支持团队分析原因。
查看 latch 堵塞
处理这类问题首先是监控是否发生了 latch 等待：
清单 6. db2pd 查看 latch 等待
AGDPCMB1:/home/db2gdpc$db2pd -latches Database Member 0 -- Active -- Up 30 days 00:11:52 -- Date 2017-12-01-17.11.29.074912 Latches: Address Holder Waiter Filename LOC LatchType HoldCount 0x0780000004F00478 1553 0 ../include/sqle_workload_disp.h 1391 SQLO_LT_sqeWLDispatcher__m_tunerLatch 1 0x0A00050000069D20 33105 589675 sqlpgResSpace.C 542 SQLO_LT_SQLP_DBCB__add_logspace_sem 1 0x0A00050000069D20 33105 528805 sqlpgResSpace.C 542 SQLO_LT_SQLP_DBCB__add_logspace_sem 1 Latch Waiters With No Holders: Address Holder Waiter Filename LOC LatchType 0x0A0005059594A800 0 529319 /view/db2_v105fp7_aix64_s151221/vbs/engn/include/sqlpt_inlines.h 2186 SQLO_LT_SQLB_BPD__bpdLatch_SX 0x0A00050225DAA938 0 415209 /view/db2_v105fp7_aix64_s151221/vbs/engn/include/sqlpt_inlines.h 2186 SQLO_LT_SQLB_BPD__bpdLatch_SX
图中的输出信息分两个主要部分。第一部分是有持有者的 latch 信息，包含有等待的和没等待的。没有等待者的持有者是不需要关心的。第二部分是找不到持有者但是有等待者的 latch 信息。相对第一部分，这个是因为持有者在内部开发的代码里没有显示给监控，并不是真的没有持有者。解读下这个输出里面的内容：
- Address：latch 地址，唯一定位一个 latch 对象。
- Holder：latch 的持有者。这是个 EDUID。
- Waiter：latch 的等待者。这是个 EDUID。
- Filename：获取这个 latch 的源文件名。
- LOC：源文件里的代码位置。
- LatchType：latch 名称。
- HoldCount：持有数量。
上面这个例子包含三种场景：
- latch 地址为 0x0780000004F00478 的持有者是 1553，等待者是 0 也就是没有等待者。这是一个正常的现象，不需要去关注。
- latch 地址为 0x0A00050000069D20 的持有者是 33105，等待者有 589675 和 528805。这是一个典型的堵塞现象。33105 堵塞了 589675 和 528805。这个 latch 的名称是 SQLO_LT_SQLP_DBCB__add_logspace_sem。
- 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
本站声明：
1、本站所有资源均来源于互联网，不保证100%完整、不提供任何技术支持；
2、本站所发布的文章以及附件仅限用于学习和研究目的;不得将用于商业或者非法用途；否则由此产生的法律后果，本站概不负责！
