DB2数据库中的锁问题(二)

分析DB2数据库的锁等待

锁，一个让人觉得安全又不太方便的技术，在数据库中发挥着他无可替代的作用，但是，不同的数据库对其有不同的实现方式。

　　锁，一个让人觉得安全又不太方便的技术，在数据库中发挥着他无可替代的作用，但是，不同的数据库对其有不同的实现方式。当你习惯一个数据库的使用方式，去接触另外一个数据库时，就会感觉到诸多的不便。每个开始接触DB2的人，或多或少的都有这样的感受，数据库中有那么多类型的锁，S,IS,NS,X,IX,SIX,NX,U,Z….从名字上看，很多差不多，如果你能都弄懂他的含义，并且在设计中考虑到，那当然是好的;如果你不是很理解他，没关系，大多数使用DB2数据库开发的人都不能完全理解他们，所以，你不用担心。作为一个DB2数据库使用比较习惯的人，这里分享下如何处理DB2数据库中的锁等待问题，帮助大家解决使用DB2过程中遇到的锁问题。

　　下面，使用一个简单的例子来介绍下如何分析数据库的中的锁等待问题。

　　场景，查找数据库锁等待的根源：

　　创建一个简单的表：

　　DB2 "create table test_lock (col int, col2 char(10))"

　　开3个命令行的窗口

　　在窗口一执行：

　　DB2 +c "insert into test_lock values(1,'aaa')"

　　DB20000I SQL命令成功完成。

　　在窗口二执行：

　　DB2 "select * from test_lock"

　　我们看到了，很长时间没有返回，这就是很多人曾经问的一个问题，我执行了一个很简单的操作，数据库卡死，不返回，为什么?

　　我们使用窗口三进行分析：

　　DB2 list applications show detail

　　XUXIAOF DB2bp.exe 22 *LOCAL.DB2.090817071951 00012 1 0 4764 UOW 正在等待 2009-08-18 10:52:08.685167 IBM-L3F6 SAMPLE C:DB2NODE0000SQL00001

　　XUXIAOF DB2bp.exe 68 *LOCAL.DB2.090817075736 00003 1 0 4464 锁定等待 2009-08-18 10:53:24.329893 IBM-L3F6 SAMPLE C:DB2NODE0000SQL00001

　　这个命令永远是你看锁问题最简单实用的一步，数据库中到底现在存在不存在锁等待，一看就知道，如果有较长时间Lock-waiting(英文环境)状态或者锁定等待(中文环境)状态，则数据库存在锁定等待的应用，如上所示，窗口2不返回的原因可能是锁等待引起的，现在，我们用DB2pd这个工具，来分析下具体锁在哪儿，也许，这才是我们最关心的。

　　DB2pd -d sample -locks show detail

　　Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg

　　0x7F8911B0 8 03000500040080020000000052 Row .NS W 2 1 0 0x00 0x00000001 TbspaceID 3 TableID 5 PartitionID 0 Page 640 Slot 4

　　执行这个命令后，你也许会看到很多的锁，我为什么会找出这条呢?记住，你分析的入手点一定是正在等待的应用程序，也就是上面所列，状态(Sts)为W(waiting)的应用，也许在你的环境中你看到了很多，可以逐个分析。

<!--分页-->

　　在这一行中，我们可以得到这些有用信息，Transaction handle为8 (TranHdl)的应用正在等待03000500040080020000000052(Lockname)这个锁，这个锁正被Transaction handle为2(Owner)的应用占有。请求的锁类型为行上的NS锁，请求锁的行是3号表空间中的5号表上，在表空间的第640页中的第4个槽位。现在，我们看下谁持有这个锁。

　　DB2pd -d sample -locks show detail |find "03000500040080020000000052"

　　0x7F890AB0 2 03000500040080020000000052 Row ..X G 2 1 0 0x08 0x40000000 TbspaceID 3 TableID 5 PartitionID 0 Page 640 Slot 4

　　0x7F8911B0 8 03000500040080020000000052 Row .NS W 2 1 0 0x00 0x00000001 TbspaceID 3 TableID 5 PartitionID 0 Page 640 Slot 4

　　看到如上2行结果，其中一行，是我们刚才看到的正在等待的应用，而另外一个，状态为G(Granted)，Transction handler为2，正是我们要找的，持有锁没释放的根源。如果你看到其他的状态为W的锁，是可能的，因为可能很多应用都在等这个锁，我们要找的是持有锁的应用，通过上一个命令的分析，是Transction handler为2的应用。

　　到此，我们已经找到了是Transaction handle为2的应用在占用锁没有释放，可以使用下面的命令来查看下，他到底在执行什么。

　　DB2pd –d sample –transactions

　　Transactions:

　　Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2

　　Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID

　　0x7FC21A80 22[000-00022] 2 3 WRITE 0x00000000 0x00000000 0x000002C1D098 0x000002C1D098 110 174 0x00000000185E 1 0

　　查找TranHdl为2的应用，我们可以看到这样的信息，这个应用application handle为22，当前持有3个锁，状态为写。注意，当LogSpace不为0的时候，这个应用一定有未提交的更改操作，这个应用使用日志为110。下面我们查下这个应用在执行什么。

　　DB2pd -d sample -applications

　　Address AppHandl [nod-index] NumAgents CoorEDUID Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID

　　0x7AED8080 22[000-00022] 1 4764 UOW-Waiting 0 0 64 1 *LOCAL.DB2.090817071951 1 1

　　找application handle为22的应用，然后查找当前语句的句柄标识和上条语句的句柄标识，我们看到，当前这个应用没有正在执行的语句，执行的上条语句是L-AnchID为64, L-StmtUID为1的语句。我们看下这个语句是什么?

　　DB2pd -d sample –dyn

　　Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text

　　0x7EAF4370 64 1 0 0 1 1 insert into test_lock values(1,'aaa')。

　　通过动态语句的对应(AnchID StmtUID分别为64和1)，我们已经找到了锁定的根源，正式上面的语句占用了锁没有释放，导致你执行的查询语句没有返回，中间，我们也理解的一些DB2pd的输出，并会利用这些信息分析问题，如果你使用的是9.5或以上的版本，还可以利用更简单的方法知道，这个锁到底在哪一行上，如上面所分析，请求的锁在3号表空间中的5号表上，在表空间的第640页中的第4个槽位。现在我们看下，是锁了哪个对象的哪行记录：

　　DB2 "select tabname from syscat.tables where tbspaceid = 3 and tableid = 5"

　　TABNAME

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

　　TEST_LOCK

　　锁在TEST_LOCK这个表上，具体是在这个表上的哪行记录呢?根据数据库ROWID的组成，pages为640和slot为4，如果是large tablespace，则rowid转换为整数为:640*65536+4，如果是regular tablespace，则rowid转换为整数为640*256+4，我使用的是large表空间，所以rowid为640*65536+4=41943044。

　　根据表和rowid可以直接找到这条记录：

　　DB2 "select * from test_lock where rid(test_lock)= 41943044 with ur"

　　COL COL2

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

　　1 aaa

　　结果和上面分析的一样，在TEST_LOCK表上的1’aaa’这行记录上产生的锁等待。注意，上面的语句要使用with ur来执行，否则，你也同样锁等待了。。。。。

　　补充一点：

　　很多情况下知道数据库的applications handle后，需要知道到底是业务的哪个进程连接过来执行的，可以使用下面的方法来查：

　　DB2pd -d smaple –agents

　　Address AppHandl [nod-index] AgentEDUID Priority Type State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt DBName

　　0x7AB97A90 22[000-00022] 4764 0 Coord Inst-Active 5120

　　XUXIAOF DB2bp.exe 245 48 NotSet SAMPLE

　　查找application handle为22的应用，对应的ClientPid为5120，就是你连接到数据库上执行这个操作的应用的进程，应用程序的名字(ClientNm)为DB2bp.exe。

 

http://soft.zdnet.com.cn/software_zone/2009/0831/1450233.shtml