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|more

Database Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:04:15 -- Date 2014-01-10-15.33.14.983796

Applications:
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:      : 1134615144

User 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:    : 551

Database Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:06:14 -- Date 2014-01-03-15.35.13.996815

Dynamic 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          35605

Dynamic 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锁问题和语句的定位方法,希望能给大家在分析和定位应用性能问题的时候起到一定的帮助。

相关内容