Month: June 2014

How to capture and analyze DB2 lock

在多用户并发系统下,出现锁等待不可避免,DB2可以只对表进行加锁,也可以对表和表中的行进行加锁。如果只对表进行加锁,则表中所有的行都受到同等程度的影响。如果加锁的范围针对于表及下属的行,则在对表加锁后,相应的数据行上还要加锁。究竟应用程序是对表加行锁还是同时加表锁和行锁,是由应用程序执行的命令和系统的隔离级别确定。
首先对几种表锁的模式加以阐述:
IS、IX、SIX方式用于表一级并需要行锁配合,他们可以阻止其他应用程序对该表加上排它锁。
如果一个应用程序获得某表的IS锁,该应用程序可获得某一行上的S锁,用于只读操作,同时其他应用程序也可以读取该行,或是对表中的其他行进行更改。
如果一个应用程序获得某表的IX锁,该应用程序可获得某一行上的X锁,用于更改操作,同时其他应用程序可以读取或更改表中的其他行。
如果一个应用程序获得某表的SIX锁,该应用程序可以获得某一行上的X锁,用于更改操作,同时其他应用程序只能对表中其他行进行只读操作。
S、U、X和Z方式用于表一级,但并不需要行锁配合,是比较严格的表加锁策略。
如果一个应用程序得到某表的S锁。该应用程序可以读表中的任何数据。同时它允许其他应用程序获得该表上的只读请求锁。如果有应用程序需要更改读该表上的数据,必须等S锁被释放。
如果一个应用程序得到某表的U锁,该应用程序可以读表中的任何数据,并最终可以通过获得表上的X锁来得到对表中任何数据的修改权。其他应用程序只能读取该表中的数据。U锁与S锁的区别主要在于更改的意图上。U锁的设计主要是为了避免两个应用程序在拥有S锁的情况下同时申请X锁而造成死锁的。
如果一个应用程序得到某表上的X锁,该应用程序可以读或修改表中的任何数据。其他应用程序不能对该表进行读或者更改操作。
如果一个应用程序得到某表上的Z锁,该应用程序可以读或修改表中的任何数据。其他应用程序,包括未提交读程序都不能对该表进行读或者更改操作。
IN锁用于表上以允许未提交读这一概念。
表一:DB2数据库表锁的模式
Table_row
表二:DB2数据库行锁的模式
row_lock
DB2锁的兼容性
表三:DB2数据库表锁的相容矩阵
table_lock_cap
表四:DB2数据库行锁的相容矩阵
row_lock_cap
当锁等待数量较多并比较 频繁时,会对系统的并发性和响应时间产生很大影响,这时需要重点关注和监控。db2pd是用来捕获和分析锁等待的重要工具。
db2pd 常用的命令组合是:

db2pd -d db_name -locks showlocks wait -tran -app -dyn > db2pd.out

-locks 显示锁相关信息;showlocks显示锁的详细信息,比如行锁所在的的表ID、表空间ID、page number和slot(数据页和slot用来定位行数据);wait只显示处于锁等待的锁信息,而忽略其他锁信息;-tra=transaction,显示事务信息;-app=application,显示应用相关信息;-dyn=dynamic sql,显示动态SQL相关信息。
现举例说明如何捕获和分析锁等待
1.设置lock wait场景

[db2inst1@xuhz ~]$ db2 +c "update honcho.t set id=8888 where id=8"   ---会话1
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz ~]$ db2 +c "update honcho.t set id=6666 where id=8"   ---会话2,目前该会话处于hang状态;

2.使用db2pd捕获lock相关信息

[db2inst1@xuhz ~]$ db2pd -d honcho -locks showlock wait -tran -app -dyn > db2pd.out

3.分析捕获的lock信息
3.1 分析lock

Database Member 0 -- Database HONCHO -- Active -- Up 0 days 02:24:42 -- Date 2014-06-26-11.53.42.110541

Locks:
Address            TranHdl    Lockname                   Type           Mode Sts Owner      Dur HoldCount  Att        ReleaseFlg rrIID TableNm            Sch
emaNm 
0x00007F67D4A4CC00 14         040004000B0000000000000052 RowLock        .NS  W   3          0   0          0x00000000 0x00000000 0     T                  HON
CHO     040004000B0000000000000052 SQLP_RECORD (obj={4;4}, rid=d(0;0;11), x0B00000000000000)
0x00007F67D4A75C00 3          040004000B0000000000000052 RowLock        ..X  G   3          1   0          0x00200020 0x40000000 0     T                  HON
CHO     040004000B0000000000000052 SQLP_RECORD (obj={4;4}, rid=d(0;0;11), x0B00000000000000)
以上是锁的信息,事务TranHdel 14处于锁等待状态,正在等待的行被TranHdl 3占据,两者Lockname相同,两事务锁类型都为行级锁,事务14的锁模式为NS,事务3的锁模式为X,这两者不能兼容,故事务14出现了锁等待。
obj={4;4} 代表了表空间ID和对象ID:
[db2inst1@xuhz ~]$ db2 "select substr(tabname,1,10) tabname,substr(tabschema,1,10) tabschema from syscat.tables where tableid=4 and tbspaceid=4"

TABNAME    TABSCHEMA 
---------- ----------
T          HONCHO    

  1 record(s) selected.
rid=d(0;0;11)代表了分区号、数据页、槽位号,通过该信息可以找到具体表的哪一行持有锁(通过rowid找到相应的行),计算方法为rowid=page_num*pagesize+slot_num,此例的rowid=0*8192*8+11=11,找出的行如下:
[db2inst1@xuhz ~]$ db2 "select * from honcho.t where rid(honcho.t)=11 with ur"

ID          NAME      
----------- ----------
       8888 honcho    

  1 record(s) selected.
Lockname,锁名称,对于一个行锁或者表锁来说,前两个字节为表空间ID;紧接着的两个字节为对象ID;然后紧接着的8个字节为RID(其中前两个字节字节代表slot ID,中间四个字节为数据页ID,最后2字节为分区ID);最后一个字节为锁类型。
本例中0400  0400  0B00 00000000 0000  52 代表为:表空间4,对象4,slot 0xB=11,数据页0,表分区0,52代表行锁。
Sts列为状态列,G的意思是Granted,就是锁被成功持有;W的意思是Wait,代表锁等待;C的意思是Convert,代表正在从一个低级别的锁升级到高级别的锁。在分析锁数据时,应该从Sts为W或者C的锁看起,然后根据对应的LockName找到相同名字的Sts为G的那一样,然后根据其第二列TranHdl得到事务句柄。

3.2 分析transaction

Database Member 0 -- Database HONCHO -- Active -- Up 0 days 02:24:42 -- Date 2014-06-26-11.53.42.110878

Transactions:
Address            AppHandl [nod-index] TranHdl    Locks      State   Tflag      Tflag2     Firstlsn           Lastlsn            Firstlso             Lastls
o              SpaceReserved   LogSpace        TID            AxRegCnt   GXID     ClientUserID                   ClientWrkstnName               ClientApplNam
e                 ClientAccntng                  
0x00007F67D4568C00 33       [000-00033] 3          3          WRITE   0x00000000 0x00000000 0x00000000000F4749 0x00000000000F474B 208225114            208225
297            411             687             0x00000000546F 1          0        n/a                            n/a                            n/a          
                  n/a                                                       
0x00007F67D4588B80 34       [000-00034] 14         4          READ    0x00000000 0x00000000 0x0000000000000000 0x0000000000000000 0                    0     
               0               0               0x000000005470 1          0        n/a                            n/a                            n/a          
                  n/a                            
以上是事务相关信息,事务3对应的AppHandl是33,上面有3个锁,事务状态为WRITE;而事务14对应的AppHandl 是34,上面有4个锁,事务状态为READ。处于等待状态事务的Firstlsn、Lastlsn、Firstlso、Lastlso都为0。

3.3 分析Application

Database Member 0 -- Database HONCHO -- Active -- Up 0 days 02:24:42 -- Date 2014-06-26-11.53.42.111850

Applications:
Address            AppHandl [nod-index] NumAgents  CoorEDUID  Status                  C-AnchID C-StmtUID  L-AnchID L-StmtUID  Appid                          
                                  WorkloadID  WorkloadOccID CollectActData          CollectActPartition     CollectSectionActuals   
0x0000000203400080 34       [000-00034] 1          22         Lock-wait               14       1          460      1          *LOCAL.db2inst1.140626014000   
                                  1           3             N                       C                       N  
0x00000002033F0080 33       [000-00033] 1          60         UOW-Waiting             0        0          992      1          *LOCAL.db2inst1.140626013918   
                                  1           2             N                       C                       N  
以上是应用相关信息,AppHandl表示应用句柄,Status表示应用状态,C-AnchID/C-StmtUID和L-AnchID/L-StmtUID对分别用来唯一标识一条SQL语句,C表示Current,当前执行的语句;L表示Last,上一条执行的语句。
在本例中应用句柄34处于Lock-wait状态,应用句柄33处于UOW-Waiting状态。C-AnchID/C-StmtUID为(14/1)的语句正处于锁等待,而(992/1)语句持有锁。

3.4 分析Dynamic SQL

Database Member 0 -- Database HONCHO -- Active -- Up 0 days 02:24:42 -- Date 2014-06-26-11.53.42.112934

Dynamic Cache:
Current Memory Used           2098602
Total Heap Size               13079511
Cache Overflow Flag           0
Number of References          1030
Number of Statement Inserts   213
Number of Statement Deletes   156
Number of Variation Inserts   65
Number of Statements          57

Dynamic SQL Statements:
Address            AnchID StmtUID    NumEnv     NumVar     NumRef     NumExe     Text 
0x00007F67DEF9DBA0 14     1          1          1          1          1          update honcho.t set id=6666
    where id=8
0x00007F67DEFEDC20 992    1          1          1          1          1          update honcho.t set id=8888
    where id=8
以上是动态SQL语句相关信息,(AnchID,StmtUID)用来唯一标识一条SQL语句,NumExe表示SQL语句执行的次数,Text表示SQL语句。
在本例中,句柄为(14,1)的语句“update honcho.t set id=6666 where id=8”正在等待句柄(992,1)的语句“update honcho.t set id=8888 where id=8”

通过以上分析得知,可以根据db2pd -locks选项定位锁信息,找到持有锁和锁等待的事务句柄,然后根据db2pd -tra选项找到这几个事务的句柄所属的应用句柄,然后根据db2pd -app找到这些应用句柄刚执行或正在执行的SQL句柄,最后根据db2pd -dyn找到这些SQL语句。
但是使用db2pd并不一定能找到引起锁等待的SQL语句。例如,如果一个事务执行完DML语句后,有进行了多次查询操作,db2pd只能抓取当前正在或上一条执行的语句,此时db2pd抓取的结果就不是真正占有锁等待的SQL语句。
举例说明:
接着上面的例子在会话1上执行以下SQL:

[db2inst1@xuhz ~]$ db2 +c "select * from honcho.t where id=8888"

ID          NAME      
----------- ----------
       8888 honcho    

  1 record(s) selected.

[db2inst1@xuhz ~]$ db2 +c "select * from honcho.t where id=100"

ID          NAME      
----------- ----------
        100 honcho    

  1 record(s) selected.

再次使用db2pd收集数据库相关信息

[db2inst1@xuhz ~]$ db2pd -d honcho -locks showlock wait -tran -app -dyn > db2pd.out
Database Member 0 -- Database HONCHO -- Active -- Up 0 days 04:39:39 -- Date 2014-06-26-14.08.39.454857

Locks:
Address            TranHdl    Lockname                   Type           Mode Sts Owner      Dur HoldCount  Att        ReleaseFlg rrIID TableNm            Sch
emaNm 
0x00007F67D4A4CC00 14         040004000B0000000000000052 RowLock        .NS  W   3          0   0          0x00000000 0x00000000 0     T                  HON
CHO     040004000B0000000000000052 SQLP_RECORD (obj={4;4}, rid=d(0;0;11), x0B00000000000000)
0x00007F67D4A75C00 3          040004000B0000000000000052 RowLock        ..X  G   3          1   0          0x00200020 0x40000000 0     T                  HON
CHO     040004000B0000000000000052 SQLP_RECORD (obj={4;4}, rid=d(0;0;11), x0B00000000000000)

Transactions:
Address            AppHandl [nod-index] TranHdl    Locks      State   Tflag      Tflag2     Firstlsn           Lastlsn            Firstlso             Lastls
o              SpaceReserved   LogSpace        TID            AxRegCnt   GXID     ClientUserID                   ClientWrkstnName               ClientApplNam
e                 ClientAccntng                  
0x00007F67D4568C00 33       [000-00033] 3          3          WRITE   0x00000000 0x00000000 0x00000000000F4749 0x00000000000F474B 208225114            208225
297            411             687             0x00000000546F 1          0        n/a                            n/a                            n/a          
                  n/a  
0x00007F67D4588B80 34       [000-00034] 14         4          READ    0x00000000 0x00000000 0x0000000000000000 0x0000000000000000 0                    0     
               0               0               0x000000005470 1          0        n/a                            n/a                            n/a          
                  n/a
                  
Applications:
Address            AppHandl [nod-index] NumAgents  CoorEDUID  Status                  C-AnchID C-StmtUID  L-AnchID L-StmtUID  Appid                          
                                  WorkloadID  WorkloadOccID CollectActData          CollectActPartition     CollectSectionActuals   
0x0000000203400080 34       [000-00034] 1          22         Lock-wait               14       1          460      1          *LOCAL.db2inst1.140626014000   
                                  1           3             N                       C                       N  
                      C                       N  
0x00000002033F0080 33       [000-00033] 1          60         UOW-Waiting             0        0          694      2          *LOCAL.db2inst1.140626013918   
                                  1           2             N                       C                       N  
Dynamic SQL Statements:
Address            AnchID StmtUID    NumEnv     NumVar     NumRef     NumExe     Text 
0x00007F67DEF9DBA0 14     1          1          1          1          1          update honcho.t set id=6666 where id=8                                  
0x00007F67DF117A00 694    2          1          1          1          1          select * from honcho.t where id=100
从上面捕获的情况来看导致句柄(14,1)“update honcho.t set id=6666 where id=8”出现锁等待的语句是由于句柄(694,2)“select * from honcho.t where id=100”,但是实际情况引起锁定的语句是“update honcho.t set id=8888 where id=8”。

为了解决db2pd的这一局限性,可以设置db2_capture_locktimeout注册变量,可以有效捕获超时和死锁语句。
4. db2_capture_locktimeout
4.1 设置参数,并创建事件监控器

[db2inst1@xuhz ~]$ db2set DB2_CAPTURE_LOCKTIMEOUT=ON  ---设置注册变量
[db2inst1@xuhz ~]$ db2 update db cfg for honcho using locktimeout 15  --设置超时
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@xuhz ~]$ db2 force application all
DB20000I  The FORCE APPLICATION command completed successfully.
DB21024I  This command is asynchronous and may not be effective immediately.
[db2inst1@xuhz ~]$ db2stop               ---注册变量需要重启后才能生效
06/26/2014 14:27:53     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.
[db2inst1@xuhz ~]$ db2start
06/26/2014 14:28:00     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

[db2inst1@xuhz lib]$ mkdir locks
[db2inst1@xuhz lib]$ db2 connect to honcho

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.5.3
 SQL authorization ID   = DB2INST1
 Local database alias   = HONCHO
[db2inst1@xuhz lib]$ db2 "create event monitor dlockevm for deadlocks with details history write to file '/home/db2inst1/lib/locks'"
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz lib]$ db2 commit
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz lib]$ db2 set event monitor dlockevm state=1   ---让事件监控器生效,设置为0 deactivate
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz lib]$ db2 commit
DB20000I  The SQL command completed successfully

4.2 创造锁超时场景

会话1:
[db2inst1@xuhz lib]$ db2 +c "update honcho.t set id=8888 where id=8"
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz lib]$ db2 +c "select * from honcho.t where id=100"

ID          NAME      
----------- ----------
        100 honcho    

  1 record(s) selected.
会话2:
[db2inst1@xuhz ~]$ db2 +c "update honcho.t set id=6666 where id=8"
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0911N  The current transaction has been rolled back because of a deadlock 
or timeout.  Reason code "68".  SQLSTATE=40001

可以看到15s中过后hang住的会话自动回滚,同时报SQL0911,Reason code 68的错误信息。

4.3 分析db2locktimout dump文件
此时会在/sqllib/db2dump目录下生产db2locktimeout.timestamp文件,该文件中包含锁请求信息和锁拥有者信息。

[db2inst1@xuhz ~]$ cd /home/db2inst1/sqllib/db2dump/
[db2inst1@xuhz db2dump]$ cat db2locktimeout.0.61.2014-06-26-14-48-18 

LOCK TIMEOUT REPORT

Date:               26/06/2014
Time:               14:48:18
Instance:           db2inst1
Database:           HONCHO
Member ID:          0


Lock Information: 

   Lock Name:      040004000B0000000000000052
   Lock Type:      Basic RECORD lock(DMS/IXM)
   Lock Specifics: (obj={4;4}, rid=d(0;0;11), x0B00000000000000)


Lock Requestor: 
   System Auth ID:          DB2INST1
   Application Handle:      [0-32]
   Application ID:          *LOCAL.db2inst1.140626064048
   Application Name:        db2bp
   Requesting Agent ID:     61
   Coordinator Agent ID:    61
   Coordinator Partition:   0
   Lock timeout Value:      15000 milliseconds
   Lock mode requested:     .NS
   Application Status:      (SQLM_LOCKWAIT)
   Current Operation:       (SQLM_EXECUTE_IMMEDIATE)
   Lock Escalation:         No

   Context of Lock Request: 
   Identification:            UOW ID (2); Activity ID (1)
   Activity Information:      
      Package Schema:         (NULLID  )
      Package Name:           (SQLC2K26NULLID  )
      Package Version:        ()
      Section Entry Number:   203
      SQL Type:               Dynamic
      Statement Type:         DML, Insert/Update/Delete
      Effective Isolation:    Cursor Stability
      Statement Unicode Flag: No
      Statement:              update honcho.t set id=6666 where id=8


Lock Owner (Representative):  
   System Auth ID:          DB2INST1
   Application Handle:      [0-7]
   Application ID:          *LOCAL.db2inst1.140626062915
   Application Name:        db2bp
   Requesting Agent ID:     22
   Coordinator Agent ID:    22
   Coordinator Partition:   0
   Lock mode held:          ..X

   List of Active SQL Statements:  Not available

   List of Inactive SQL Statements from current UOW:  

      Entry:                  #1
      Identification:         UOW ID (6); Activity ID (2)
      Package Schema:         (NULLID  )
      Package Name:           (SQLC2K26)
      Package Version:        ()
      Section Entry Number:   201
      SQL Type:               Dynamic
      Statement Type:         DML, Select (blockable)
      Effective Isolation:    Cursor Stability
      Statement Unicode Flag: No
      Statement:              select * from honcho.t where id=100

      Entry:                  #2
      Identification:         UOW ID (6); Activity ID (1)
      Package Schema:         (NULLID  )
      Package Name:           (SQLC2K26)
      Package Version:        ()
      Section Entry Number:   203
      SQL Type:               Dynamic
      Statement Type:         DML, Insert/Update/Delete
      Effective Isolation:    Cursor Stability
      Statement Unicode Flag: No
      Statement:              update honcho.t set id=8888 where id=8  ---找到了引起死锁的语句

注:仅仅设置db2_capture_locktimeout注册变量是不够的,还必须创建一个死锁事件监控器才能完整捕获锁超时相关的语句信息。如果不创建那么在dump文件中看到如下的信息为:List of Inactive SQL Statements from current UOW: Not available。构建锁定超时报告需要用到死锁事件监视器代码交付的功能,使用details history选项创建死锁事件监控器时,db2跟踪已经在事务中执行的SQL语句。如果发生死锁或者锁定超时,这个信息可以用于提供SQL语句的历史信息,这些SQL语句可能与死锁或锁超时是发生有关。
5.使用锁事件监控器来捕获
在DB2 9.7中引入了锁事件监控器模型,使用统一的方法来不过超时、锁等待和死锁。
5.1 设置相关参数

[db2inst1@xuhz ~]$ db2 update db cfg for honcho using mon_lockwait hist_and_values
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@xuhz ~]$ db2 update db cfg for honcho using mon_deadlock hist_and_values
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@xuhz ~]$ db2 update db cfg for honcho using mon_locktimeout hist_and_values
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@xuhz ~]$ db2 update db cfg for honcho using mon_lw_thresh 10000    ----锁等待超过10s开始捕获相关信息
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@xuhz ~]$ db2 get db cfg for honcho |grep -i MON
Lock timeout events                   (MON_LOCKTIMEOUT) = HIST_AND_VALUES
 Deadlock events                          (MON_DEADLOCK) = HIST_AND_VALUES
 Lock wait events                         (MON_LOCKWAIT) = HIST_AND_VALUES
 Lock wait event threshold               (MON_LW_THRESH) = 10000

5.2 创建锁监视器

[db2inst1@xuhz ~]$ db2 "create event monitor lockevmon for locking write to unformatted event table (table locks)"
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz ~]$ db2 commit
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz ~]$ db2 set event monitor lockevmon state=1
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz ~]$ db2 commit
DB20000I  The SQL command completed successfully.

Write to unformated event table选项会将锁事件写到未格式化的表里(unformated event table ,UE),对未格式化表(UE表)的维护:
>.创建独立的表空间,考虑到内联LOB的高效率,创建独立的pagesize为32页的表空间;
>.当锁事件发生频繁时,会导致UE表增长很快,建议定期删除不需要的数据。在删除前需要将event monitor state设置为0将事件监控器关闭;
>.当不需要锁事件监控器时,可以drop掉,UE表需要手动删除。

5.3 创造锁超时场景

会话1:
[db2inst1@xuhz lib]$ db2 +c "update honcho.t set id=8888 where id=8"
DB20000I  The SQL command completed successfully.
[db2inst1@xuhz lib]$ db2 +c "select * from honcho.t where id=100"

ID          NAME      
----------- ----------
        100 honcho    

  1 record(s) selected.
会话2:
[db2inst1@xuhz ~]$ db2 +c "update honcho.t set id=6666 where id=8"
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0911N  The current transaction has been rolled back because of a deadlock 
or timeout.  Reason code "68".  SQLSTATE=40001

5.4 使用sysproc.evmon_format_ue_to_tables存储过程格式化未格式表

[db2inst1@xuhz ~]$ db2 "call sysproc.evmon_format_ue_to_tables('LOCKING',NULL,NULL,NULL,NULL,NULL,'RECREATE_FORCE',-1,'SELECT * FROM locks order by event_timestamp')"

  Return Status = 0

这个存储过程的结果是一组关系表
LOCK_EVENT表对应发生的锁事件,每个事件对应一条记录;
LOCK_PARTICIPANTS表标识锁事件的参与者;
LOCK_PARTICIPANT_ACTIVITIES表包含了参与事件的应用程序曾经和当前正在执行的语句。

通过SQL语句对锁相关事件进行查询

[db2inst1@xuhz ~]$ db2 "select substr(lp.xmlid,1,64) xmlid,lp.participant_type,varchar(lpa.stmt_text,50) statement from lock_participants lp, lock_participant_activities lpa where lp.xmlid=lpa.xmlid and lp.participant_no=lpa.participant_no order by lp.xmlid desc, lp.participant_no,lpa.activity_id"

XMLID                                                            PARTICIPANT_TYPE STATEMENT                                         
---------------------------------------------------------------- ---------------- --------------------------------------------------
db2LockEvent_2_LOCKTIMEOUT_2014-06-26-15.46.58.248666_0          Requester        update honcho.t set id=6666 where id=8            
db2LockEvent_2_LOCKTIMEOUT_2014-06-26-15.46.58.248666_0          Owner            update honcho.t set id=8888 where id=8            
db2LockEvent_2_LOCKTIMEOUT_2014-06-26-15.46.58.248666_0          Owner            select * from honcho.t where id=100               
db2LockEvent_1_LOCKWAIT_2014-06-26-15.46.42.893796_0             Requester        update honcho.t set id=6666 where id=8            
db2LockEvent_1_LOCKWAIT_2014-06-26-15.46.42.893796_0             Owner            update honcho.t set id=8888 where id=8            
db2LockEvent_1_LOCKWAIT_2014-06-26-15.46.42.893796_0             Owner            select * from honcho.t where id=100

LOCKWAIT表示锁等待、LOCKTIMEOUT表示锁超时、DEADLOCK表示死锁。

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569