奉行极客精神
成就客户价值

1. 手工模拟锁现象：
在XXXXDBS12主机的XXXXDB 数据库上新建一张 MY_TEST的测试表，导入94164 行数据。

 
1） 使用LOCK TABLE 命令使用排他方式持有 MY_TEST 的表级锁。

2） 在cursor stability （CS）隔离级别下使用select命令来访问该表

此时形成了锁等待现象：

Agent id 为 46976 的LOCK TABLE 应用持有 MY_TEST的表级锁，而Agent id 为 46978的SELECT 应用正处于锁等待状态，等待着LOCK TABLE 应用所持有的锁。
 
2. 通过DB2PD监控模块来加以分析 （找到锁冲突应用和相应SQL）
现在我们只知道在15:58分左右有个应用因为锁等待超时而回滚了，那我们怎么通过DB2PD监控模块来分析回滚原因呢？

DB2PD监控模块排查具体操作步骤如下：
1）打开FOGLIGHT界面，点击左边菜单中的DB2PD Database Home 一项 ，再选择要监控的主机XXXXXDBS12

2) 进入界面后首先选择时间段，时间段此处选择从15：30~16:02分，确认后点击Apply

3) 选择DB2PD的lock 字段，先观察此段时间内是否有锁等待，下图中tranHdl为40的事务正处于Lock Waiting 状态；而占有该锁的事务 tranHdl 为18 (通过owner 18可确定)

1） 选择DB2PD的Transcation字段，找到tranHdl 40 与 18 所对应的appHandl分别为46978 与 46976

2） 选择DB2PD的Application字段，找到appHandl分别为46978 与 46976 所对应的上一个动态SQL缓冲池的散列锚 l_AnchId ,l_StmtUId 分别为 194 ，1 与 173 ，2

（从现场手工抓取的db2pd命令中，应从当前的动态SQL缓冲池的散列锚 C-AnchID ,C-StmtUID中选取SQL）

 
6) 选择DB2PD的Dynamic字段，查看上一个动态SQL缓冲池的散列锚 l_AnchId ,l_StmtUId  194 ，1 与 173 ，2  对应的SQL 分别为 ：
select * from my_test
lock table my_test in exclusive mode


结论：
1） 目前DB2PD监控模块一共会对db2pd命令中的apinfo, dynamic, locks, applications，transactions 参数进行抓取和格式化，通过上述历史数据即可分析历史锁问题。
2）上述案例仅测试了动态SQL的抓取，静态SQL的抓取也可从apinfo字段中得出。
3）DB2PD监控模块对所抓取的SQL语句最大长度已进行了优化，现在可最长抓取2048个字符的SQL语句。