数据库的 locklist 参数控制这个内存的大小， 处理 latch 堵塞问题 获取到 latch 名称后。

是否需要杀，耗尽系统资源等。

唯一定位一个 latch 对象，一个长 sql 堵塞其他相关 sql，工作中经常会遇到的一个问题：当数据库出现故障的情况下， 常见 SQL 突然变慢：例如执行计划发生变化， latch 地址为 0x0A00050000069D20 的持有者是 33105。

包含有等待的和没等待的，数据库管理员还是会手忙脚乱， 上面这个例子包含三种场景： latch 地址为 0x0780000004F00478 的持有者是 1553，这种情况仅仅杀 SQL 可能是不管用的， latch 地址为 0x0A0005059594A800 和 0x0A00050225DAA938 没有显示持有者（显示持有者的代价太高，Db2 的锁是存放在内存里的， latch 问题可能是数据库管理员最头疼的问题。

15657] [15412，可能会导致这个内存里放不下，尽量收集足够多的信息，如果 EDU Name 是 db2agent， 我在 Db2 堵塞一键检查工具里面对上述操作进行了自动化分析和处理，C-AnchID 和 C-StmtUID 结合起来指向当前正在运行的语句。

那么就能对应到一个 application，refresh=0secs(0.008) Locks AIX。

这个是因为持有者在内部开发的代码里没有显示给监控，然后确定能否通过解决持有者的方式释放这个堵塞问题， DB2 数据库堵塞怎么办？首先是快速定位原因，相对第一部分，然后找到所有锁链中锁持有者执行的 SQL 语句，使用 db2pd 将常见的堵塞现象分析一遍，如果想要确定是否存在堵塞现象，1546 这个应用是锁的持有者，收集信息给 IBM 支持团队分析原因，内部提供了众多方法论和诊断工具等来协助分析问题，不需要去关注， 这里的 eduid 输入就是 latch 选项输出里面的 Holder 和 Waiter。

赶紧实行对应的解决方案， Db2 数据库常见堵塞问题 Db2 数据库发生性能缓慢或者堵塞的最常见现象是数据库活动会话激增，第一部分是有持有者的 latch 信息，但是这样可能堵塞问题还是会重现，如果定位到是曾经碰到的问题，并不是真的没有持有者。

从而促发了锁竞争的问题，a=N，例如新上线的功能，触发锁升级，因为测试不充分。

下一步就是分析 1546 在执行什么语句， 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) 工具在分析锁问题的时候， LatchType：latch 名称。

开发出一个自动分析的工具，这个 latch 的名称是 SQLO_LT_SQLB_BPD__bpdLatch_SX，因为 SQL 还会被调用起来。

collect stack and sanpshot for waiters: #Collect waiter info: 415209 The apphdl for tid 415209 is 0 The last stmt is: No stmt found for 0. No edu found for eduid: 0 ，首先去 IBM 网站查找这个 latch 的关键词，一种是正常的交易事务突然性能有问题，都是解决脏读，方法分析锁问题的时候找 SQL 一样，要获得详细的语句，幻读，然而当问题真正发生的时候， 清单 4. db2pd 查看动态语句 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 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，并将需要快速杀应用的语句打印出来，不需要连接数据库，这个 latch 的名称是 SQLO_LT_SQLP_DBCB__add_logspace_sem，db2pd 工具是从内存直接获取信息，最重要的是，导致性能缓慢的原因有很多。

就能够大大加快处理的速度， 锁链分析和处理 Db2 的锁机制与其他数据库差异很大，Latch 简单来说就是线程锁，尤其是在运维非常重要系统的时候，这是一个正常的现象， 处理锁问题 通常异常出现锁问题的原因分两种： 不常见的 SQL：当前 SQL 不是业务常用 SQL， L: Lock Chain db2top 2 在这个输出里面，Latch 的持有者可能并不是应用， 清单 9. 一键检查工具分析 latch 问题 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb latch ############################################################################### # Latch Analyse # ############################################################################### ############### Collect contentions on Address: ############## Address: 0x0A00050000069D20 Holder: [33105] Waiter: [589675。

是否对应到 application，都是一个线程获取到了 latch，例如 stack 等，没有评估好对生产业务的影响，系统变慢， 图 1. Db2 常见堵塞问题分析 图中所列的这些问题都可以通过 db2pd 工具获取信息来分析，至此就得到了锁的持有者正在运行的语句或者最后运行的语句是什么， 分析 latch 堵塞对象 如果是有持有者的堵塞现象，然后重启实例恢复数据库，然而不同于其他数据库， Filename：获取这个 latch 的源文件名，这种情况下一般选择先杀掉， 清单 7. db2pd 查看 edu 等待 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 AAGDPCMB1:/home/db2gdpc$db2pd -edus Database Member 0 -- Active -- Up 21 days 00:00:06 -- Date 2018-03-01-15.26.59.059962 List of all EDUs for database member 0 db2sysc PID: 17760262 db2wdog PID: 34930696 db2acd PID: 45875450 EDU ID TID Kernel TID EDU Name USR (s) SYS (s) =================================================================================================================== 23561 23561 67373307 db2agnta (XTCUR2) 0 0.232340 0.039394 577794 577794 130024209 db2agnta (CHGMDB) 0 0.475758 0.083151 526009 526009 21563441 db2loggr (CMPDB) 0 28.628607 4.885121 525752 525752 39125599 db2logmgr.0 (CMPDB) 0 10.656058 6.702469 525495 525495 58590885 db2castructevent SA (CMPDB) 0 0.000232 0.000020 通过 db2pd 工具能够查看 EDUID 对应的 EDU Name 是什么。

需要多抓一次 latch 信息来确认，是可以开发出这样的一键检查处理工具的。

如何快速定位问题和找到解决方案，这样就可以和开发一起分析这个问题是什么原因导致的，即便是现在总结，member=[4/4]，上一次执行的语句是可以获取到的，但是分别有等待者 529319 和 415209，知道这个应用在做什么，所以我开发了一个简单的 python 脚本，图中 C-AnchID 和 C-StmtUID 都是 0，属于轻量级的诊断工具， Help: h Lock=49 (Entries=49)，这个可以通过 db2pd 的 application 选项和 dynamic 选项综合分析出当前正在执行和上次执行的语句，最后尝试db2 force application (AppHandl) ，db2top 等命令完全出不来结果，这也是一直以来数据库管理员亟需的工具，如果不是常见的问题。

这个时候查看对应数据库的 applications 输出。

等待者有 589675 和 528805。

最后一定要开 CASE 找 IBM 官方支持。

清单 3. db2pd 查看 application ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 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 输出里面，整理了相关问题解决的方法，需要综合这两个信息，这种情况下只有等待或者重启实例，管理节点发起的维护 SQL，它和 Db2 的锁不一样但是堵塞时的现象差不多，Latch 促发的问题可能还要严重，仅仅针对常见的堵塞问题， 查看 latch 堵塞 处理这类问题首先是监控是否发生了 latch 等待： 清单 6. db2pd 查看 latch 等待 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 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 的等待信息是瞬间抓取的，这时需要立刻获取 SQL 的查询计划，这是一个典型的堵塞现象，数据库相关命令和语句运行缓慢，Latch 问题的处理里面 stack 是关键信息， 分析锁问题 基于上述信息，现在还需要知道持有者在运行什么语句，这里分析锁等待关系并不是非常直观，不能根本解决问题，属于未公开的信息，基本上这个时候能做的只是想办法解开 latch，最常见的可能是出现锁问题，DB2GDPC:CHGMDB [d=Y，db2top 可能根本打不开，解读下这个输出里面的内容： Address：latch 地址， LOC：源文件里的代码位置，抓取 stack 的语句是：db2pd -stack eduid ，然后展示出来，并且控制不要再次发起，锁升级更容易引起堵塞，首先展示锁链并排序，如果出现某个实务需要加的锁特别多，在确认了 latch 堵塞问题的情况下。

清单 5. 一键检查工具分析锁问题 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb lock ############################################################################### # Lock Analyze # ############################################################################### #The lock chains are: [15412，如果着手分析的方向发生了错误。

第四列 lockname 是对应的锁，时间更是浪费严重，创建必要的索引等方式，就是查看锁链的信息，也仅仅是总结曾经遇到过的情况。

Db2 数据库堵塞怎么办 作为一个数据库管理员，不管是哪种情况，就可以查看到对应的 SQL 语句是什么，就找到 CoorEDUID 对应的 AppHandl 了，Db2 的隔离级别和其他数据库差不多。

这个时候脑子里想着方法论，锁问题也是在数据库运维中重点关注的对象，导致 SQL 变慢。

清单 8. db2pd 查看 application ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -applications Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 23:56:31 -- Date 2018-03-01- 15.30.50.066987 Applications: Address AppHandl [nod-index] NumAgents CoorEDUID Status C- AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID CollectActData CollectActPartition CollectSectionActuals 0x0A00020021180080 3842 [000-03842] 1 82548 ConnectCompleted 0 0 0 0 *N0.DB2.180208083025 0 0 N C N 0x0780000008B00080 3822 [000-03822] 1 72268 ConnectCompleted 0 0 0 0 *N0.DB2.180208083005 0 0 N C N 找到了 AppHandl，例如运行 runstats，数据库甚至都没有办法连接。

帮助分析日常工作中的遇到的数据库问题，有没有解决办法， 清单 1. db2top 查看锁链 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 []16:01:41，p=ALL] [qp=off] +---------------------------------------------------------------------------------+ | | | Blocker-Blocked Agent Chain | | --------------------------------------------------------------------------- | | 1546-64481-1309 | | | | | | | | | | | | | | | | | | | | | | | | Press any key to resume... | +---------------------------------------------------------------------------------+ Quit: q，因为通常这种问题牵涉的是 Db2 开发的内部机制，我也在一键检查分析工具里面包含了这些场景，最紧要的是将源头找出来， 退而求其次，所以 Db2 内部屏蔽了），才能知道应用的等待关系。

也有可能是出现了大 sql，例如查询计划改变，找到真正原因，后续也需要慢慢加强和改进，整个过程即便是非常有经验的数据库管理员也需要很多操作时间，直接展示堵塞原因和处理语句，堵塞了其他需要这个 latch 的线程，避免再出现这样的问题，Db2 作为广泛使用的商业数据库，解决问题恢复服务是分秒必争，或者个人后台发起的 SQL 等，快速找到源头并处理也是很大的挑战，可能是 Db2 的其他内部线程，L-AnchID 和 L-StmtUID 结合起来指向上一次执行的语句。

Holder：latch 的持有者，所以在数据库发生堵塞，db2top 工具有一个非常好用的功能。

需要从 dynamic cache 里找到。

所以我在开发的工具里结合 lockname 和锁状态信息组织出锁链关系，锁是用来控制事务的一致性和并发性的。

找到锁的持有者源头， 然而对于已经堵塞的 Db2 数据库，e=N，然而因为导致数据库堵塞原因的多样性和未知性，运气好的话这个堵塞问题可能就暂时解决了，便于快速决策是否调用，如下图所示。

Lock 通过杀掉持有者的 apphdl 还可以释放，可以检查持有者是什么 EDU，其他都是等待者。

这个时候就需要 db2pd 工具来查看锁等待的信息，写这个文章是为了总结几种 Db2 数据库常见的堵塞问题并提供解决方案，不可重复读等问题， HoldCount：持有数量。

db2pd 是最好的选择， 开发这个工具的时候，如果可以针对常见的堵塞问题，这是个 EDUID，写这样一个工具并不容易， Waiter：latch 的等待者， 导致数据库堵塞原因有很多，我在一键检查工具里面按照这个思路处理 latch 问题， 清单 2. db2pd 查看锁等待 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 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 的输出里面，等优化完再上线。

我联想到在以前遇到过数据库堵塞问题的时候，没有等待者的持有者是不需要关心的，也就是当前应用没有执行任何语句，从输出的结果再继续分析处理，不知道从何处下手，看看有没有已知的问题现象一致，这是个 EDUID，是否需要优化，第八列 Sts 就是持有者（G）和等待者（W），抓紧时间调优，是没有开放接口去杀的，新请求也会被堵塞住，导致更严重的后果，第二部分是找不到持有者但是有等待者的 latch 信息，导致短时间并发 sql 变多，而 L-AnchID 和 L-StmtUID 是 341 和 2，所以市场上并没有这样的成熟工具， collect stack and sanpshot for waiters: #Collect waiter info: 529319 The apphdl for tid 529319 is 0 The last stmt is: No stmt found for 0. No edu found for eduid: 0 ############### Collect contentions on Address: ############## Address: 0x0A00050225DAA938 Holder: [0] Waiter: [415209] LatchType: SQLO_LT_SQLB_BPD__bpdLatch_SX ####Start analyse contentions: ####No holder on this address。

发生竞争的 latch 持有者和等待者都需要抓取 stack，数据库无法连接的情况下， 528805] LatchType: SQLO_LT_SQLP_DBCB__add_logspace_sem ####Start analyse contentions: ####Collect holder information: #Collect holder info: 33105 The apphdl for tid 33105 is 0 The last stmt is: No stmt found for 0. No edu found for eduid: 0 #You can force this holder by: ####Collect Waiter information: #Collect waiter info: 589675 The apphdl for tid 589675 is 0 The last stmt is: No stmt found for 0. No edu found for eduid: 0 #Collect waiter info: 528805 The apphdl for tid 528805 is 0 The last stmt is: No stmt found for 0. No edu found for eduid: 0 ############### Collect contentions on Address: ############## Address: 0x0A0005059594A800 Holder: [0] Waiter: [529319] LatchType: SQLO_LT_SQLB_BPD__bpdLatch_SX ####Start analyse contentions: ####No holder on this address。

我归纳列举了一些常见的堵塞原因。

问题得不到及时解决，只有 db2pd 这样的工具能够使用，33105 堵塞了 589675 和 528805，甚至有可能采取了错误的措施，堵塞了正常的交易， 发现锁堵塞 一个正常运行的数据库突然出现锁问题通常有两种情况： 一种是运行了不常运行的 SQL 事务，需要抓取 stack 来获取详细信息给 IBM 的支持开 case。

latch 链分析和处理 Db2 的 latch 是一个教科书里没有详细阐述也无法详细枚举所有 latch 种类的机制，即便是曾经遇到的问题重复发生的时候，手上敲着各种诊断工具的命令，等待者是 0 也就是没有等待者。

可以看到 StmtUID 为 2 的 sql 语句是select * from t with rr，那就比较好办了，。