DB2诊断系列之---定位锁等待问题

　　在DB2应用中，我们经常会碰到sql执行很慢，但是数据库cpu和内存使用率又不高的情况，类似的问题基本上由于锁，排序等原因造成，本文主要描述如何去定位锁等待问题，谁在锁等待?等待谁持有的锁?锁在那个表?

　　一、测试准备

　　1、先在session1执行如下操作，创建测试表

　　#db2 connect to eos
　　#export DB2OPTIONS=+C
　　#db2 "create table tacy_test (a int not null primary key,b varchar(10))"
　　#db2 "insert into tacy_test values(1,'a')"
　　#db2 "insert into tacy_test values(2,'a')"
　　#db2 "insert into tacy_test values(3,'a')"
　　#db2 "insert into tacy_test values(4,'a')"
　　#db2 commit

　　2、在session2执行如下操作

　　#db2 connect to eos
　　#export DB2OPTIONS=+C

　　二、产生一个lock wait

　　在session1做一个表更新：

　　#db2 "update tacy_test set b='b' where a=4"

　　sql执行成功

　　在session2做同样更新操作：

　　#db2 "update tacy_test set b='c' where a=4"

　　进程被挂起等待

　　三、定位锁等待

　　1、先来看看应用的情况：

　　#db2pd -db eos -applications

　　Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:37:37

　　Applications:

　　Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid

　　0x10140040 8 [000-00008] 1 8425 Lock-wait 80 2 66 1 *LOCAL.db2inst1.071124043739

　　0x100CE540 7 [000-00007] 1 8358 UOW-Waiting 0 0 80 2 *LOCAL.db2inst1.071124043708

　　可以看到有一个应用的状态处于Lock-wait

　　2、现在我们来看看应用在等什么

　　#db2pd -db eos -locks showlock wait

　　Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:42:56

　　Locks:

　　Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse

　　0x2C8E0760 3 02001806078066020000000052 Row ..X W 2 1 0 0 0x0 TbspaceID 2 TableID 1560 RecordID 0x2668007

　　锁的类型为Row(行锁)，X锁(排他锁)，下面是我们最关心的锁的位置

　　TbspaceID 2 TableID 1560 RecordID 0x2668007

　　其中TbspaceID为表空间ID，TableID为表的ID，RecordID代表具体位置，全部应该是0x0266807,其中前面三个字节为page number，为0x02668，后面一个字节代表solt identifier，为0x07

　　3、找到相应的表

　　#db2 "select tbspace,tabschema,tabname,tableid,tbspaceid from syscat.tables where tbspaceid=2 and tableid=1560"

　　TBSPACE TABSCHEMA TABNAME TABLEID TBSPACEID

　　------------ ----------- ---------- ------- ---------

　　USERSPACE1 DB2INST1 TACY_TEST 1560 2

　　1 record(s) selected.