DB2锁等待的工作原理与相关问题的描述

数据库
以下的文章主要向大家讲述的是DB2锁等待的应用原理,以及对DB2数据库锁等待在实际操作中出现的相关问题的描述,以下就是文章的主要内容讲述。

今天主要向大家讲述的是DB2锁等待,此篇文章主要是通过一个简单的例子,来对数据库锁进行介绍,以及对数据库的中的锁等待问题进行详细分析,锁,一个让人觉得安全又不太方便的技术,在数据库中发挥着他无可替代的作用。

但是,不同的数据库对其有不同的实现方式。当你习惯一个数据库的使用方式,去接触另外一个数据库时,就会感觉到诸多的不便。每个开始接触DB2的人,或多或少的都有这样的感受,数据库中有那么多类型的锁,S,IS,NS,X,IX,SIX,NX,U,Z….从名字上看,很多差不多,如果你能都弄懂他的含义.

并且在设计中考虑到,那当然是好的;如果你不是很理解他,没关系,大多数使用DB2数据库开发的人都不能完全理解他们,所以,你不用担心。作为一个DB2数据库使用比较习惯的人,这里分享下如何处理DB2锁等待问题,帮助大家解决使用DB2过程中遇到的锁问题。

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

 

场景,查找数据库锁等待的根源:

 

创建一个简单的表:

 

  1. db2 "create table test_lock (col int, col2 char(10))"  

开3个命令行的窗口

在窗口一执行:

 

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

DB20000I SQL命令成功完成。

在窗口二执行:

 

  1. 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:\DB2\NODE0000\SQL00001\

 

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

 

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

 

  1. db2pd -d sample -locks show detail  
  2. Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg  
  3. 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个槽位。现在,我们看下谁持有这个锁。

 

  1. db2pd -d sample -locks show detail |find "03000500040080020000000052"  
  2. 0x7F890AB0 2 03000500040080020000000052 Row ..X G 2 1 0 0x08 0x40000000 TbspaceID 3 TableID 5 PartitionID 0 Page 640 Slot 4  
  3. 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的应用在占用锁没有释放,可以使用下面的命令来查看下,他到底在执行什么。

 

  1. db2pd –d sample –transactions  
  2. Transactions:  
  3. Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2  
  4. Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID  
  5. 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。下面我们查下这个应用在执行什么。

  1. db2pd -d sample -applications  
  2. Address AppHandl [nod-index] NumAgents CoorEDUID Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID  
  3. 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的语句。我们看下这个语句是什么?

  1. db2pd -d sample –dyn  
  2. Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text  
  3. 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个槽位。现在我们看下,是锁了哪个对象的哪行记录:

 

  1. db2 "select tabname from syscat.tables where tbspaceid = 3 and tableid = 5"  
  2. TABNAME  
  3. 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可以直接找到这条记录:

 

  1. db2 "select * from test_lock where rid(test_lock)= 41943044 with ur"  
  2. COL COL2  
  3. 1 aaa  

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

补充一点:

 

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

 

  1. db2pd -d smaple –agents  
  2. Address AppHandl [nod-index] AgentEDUID Priority Type State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt DBName  
  3. 0x7AB97A90 22[000-00022] 4764 0 Coord Inst-Active 5120  
  4. XUXIAOF db2bp.exe 245 48 NotSet SAMPLE  

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

【编辑推荐】

  1. DB2 9.7自治事务的定义与相关事务背景
  2. DB2归档日志的管理方案从哪几点入手?
  3. 对DB2取得当前时间的正确解析
  4. DB2性能调优中存在哪些问题,如何破解?
  5. DB2 数据类型如何才能轻松接触?
责任编辑:佚名 来源: 万国数据
相关推荐

2010-08-19 09:54:42

DB2死锁

2010-08-02 17:30:30

DB2锁等待

2010-08-06 13:20:00

DB2锁等待

2010-08-04 13:30:49

2010-08-10 13:36:00

2010-08-17 13:47:09

DB2还原

2010-08-18 09:50:29

DB2缓冲池

2010-08-09 10:00:25

DB2数据移动

2010-07-30 10:24:18

2010-08-17 16:24:32

IBM DB2数据库

2010-08-13 14:46:08

DB2 -964

2010-11-02 16:31:59

DB2锁的属性

2010-07-28 11:13:04

DB2 Resotre

2010-08-04 09:45:30

2010-08-04 17:10:37

DB2数据库

2010-07-28 09:21:25

DB2锁等待

2009-05-19 09:10:26

代理工作代理DB2

2010-09-07 09:31:03

DB2数据库锁表

2010-08-06 14:52:13

DB2 9.7武器

2010-08-13 15:42:22

DB2数据库分区
点赞
收藏

51CTO技术栈公众号