DB2中如何快速定位锁等待语句

在DB2中，我们经常会碰到sql执行很慢，但是数据库cpu和内存使用率又不高的情况，类似的问题基本上由于锁、排序等原因造成的。下面就从一个实例来分析如何去快速定位锁等待问题以及锁在那个表。一、锁在日志中的信息
当你在DB2DIAG.LOG中发现大量911时，一般都是有锁等待问题。
2014-01-03-10.05.26.616285+480 I4936115E839 LEVEL: Severe
PID : 16724 TID : 47174238857536PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : PORTALDB
APPHDL : 0-47283 APPID: 10.4.125.115.38673.140109201531
AUTHID : IPORTAL
EDUID : 88 EDUNAME: db2agent （PORTALDB） 0
FUNCTION: DB2 UDB, relation data serv, sqlrr_array_input, probe:210
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -911 sqlerrml: 1
sqlerrmc: 2
sqlerrp : SQLRI2C4
sqlerrd : （1） 0x80100002 （2） 0x00000002 （3） 0x00000000
（4） 0x00000000 （5） 0xFFFFFE0C （6） 0x00000000
sqlwarn : （1）（2）（3）（4）（5）（6）
（7）（8）（9）（10）（11）二、DB2PD分析锁等待
$db2pd -db portaldb -app|moreDatabase Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:04:15 -- Date 2014-01-10-15.33.14.983796Applications:
Address AppHandl [nod-index] NumAgents CoorEDUID Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
WorkloadID WorkloadOccID CollectActData CollectActPartition CollectSectionActuals
0x0000000201050080 26 [000-00026] 1 61 ConnectCompleted 0 0 0 0 *LOCAL.DB2.131224002909
0 0 N C N
0x0000000201450080 47914 [000-47914] 1 104 UOW-Waiting 0 0 677 41 10.4.125.114.11658.140110014742
1 3694 N C N
0x0000000200F80080 19 [000-00019] 1 54 UOW-Waiting 0 0 0 0 *LOCAL.DB2.131224002902
0 0 N C N 进一步分析找到applid为47914的 anchid
$db2pd -db portaldb -app|grep -i "47914"
0x0000000201450080 47914 [000-47914] 1 104 UOW-Waiting 0 0 98 1 10.4.125.114.11658.140110014742 1 3694 N C N
0x0000000201450080 47914 [000-47914] 10.4.125.114 None IPORTAL
0x0000000201450080 47914 [000-47914] n/a --anchid 为98
--然后使用db2pd -dynamic 功能, 根据anch =98 查找出该47914应用id号对应的正在执行的sql（v9以上版本适用,v8版本db2pd -dynamic无anch= **这个选项）
$db2pd -db portaldb -dynamic anch=98|more
System Temp Table Stats:
Number of System Temp Tables : 69817
Comp Eligible Sys Temps : 0
Compressed Sys Temps : 0
Total Sys Temp Bytes Stored : 16140381976
Total Sys Temp Bytes Saved : 0
Total Sys Temp Compressed Rows : 0
Total Sys Temp Table Rows: : 1134615144User Temp Table Stats:
Number of User Temp Tables : 720
Comp Eligible User Temps : 0
Compressed User Temps : 0
Total User Temp Bytes Stored : 90045
Total User Temp Bytes Saved : 0
Total User Temp Compressed Rows : 0
Total User Temp Table Rows: : 551Database Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:06:14 -- Date 2014-01-03-15.35.13.996815Dynamic Cache:
Current Memory Used 733842896
Total Heap Size 1675218370
Cache Overflow Flag 0
Number of References 19142165
Number of Statement Inserts 151614
Number of Statement Deletes 116009
Number of Variation Inserts 116930
Number of Statements 35605Dynamic SQL Statements:
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0x00002AEA103CF0C0 98 90 1 1 1 1 select count（*） as col_0_0 from KC_USER user0_ where user0_.USER_ID=349289---同样也可以使用获取快照的方式来看当前applid为47914的application在执行什么sql
$db2 get snapshot for application agentid 47914当你发现是这样一条查询语句发生了锁等，可以立即终止锁等
方法是：
$db2 "force application（47914）"
注：后来联系开发，知道他们正在修改KC_USER表，长时间没有提交，所以造成了大量有关这个表的锁等。事务提交后，该问题解决。
总结：通过上面的实例分析，我们简单描述了一个db2锁问题和语句的定位方法，希望能给大家在分析和定位应用性能问题的时候起到一定的帮助。MySQL5.5以上版本编译安装与配置MySQL Proxy 安装与读写分离体验相关资讯 DB2 DB2语句等待语句

RHEL5 下安装 DB2 V9.7 数据库（今 09:39）
DB2常用脚本整理（01月19日）
Linux下DB2SQL1024N A database （01月12日）

DB2中REVERSE函数的实现（01月19日）
使用 IBM Data Studio 创建和管理（01月12日）
TOAD连接DB2报错SQL1460N解决（01月12日）

本文评论查看全部评论（0）