DB2 死锁

[IBM][CLIDriver][DB2/6000]SQL0911N因为死锁或超时，当前事务已被回滚。原因码为"68"。SQLSTATE=40001

或者是

[IBM][CLIDriver][DB2/6000]SQL0911N因为死锁或超时，当前事务已被回滚。原因码为"2"。SQLSTATE=40001

以下是我查找原因和解决问题的方法和步骤，与大家共享。

1.调整数据库参数LOCKLIST,MAXLOCKS,LOCKTIMEOUT,DLCHKTIME

参数说明：

LOCKLIST就是锁资资源大小，实际上就是以KB为单位的内存。

MAXLOCKS是一个应用程序实际使用的锁资源所占用的LOCKLIST的比例，当超过这个比例时，锁就会产生升级。

LOCKTIMEOUT锁等待超时时间，以秒为单位。当应用程序提出所资源申请时，如果超过了这个时间而没有得到就会产生锁定超时。

DLCHKTIME是检测死锁的时间间隔，以毫秒为单位。

增大LOCKLIST.

首先查看数据库参数getdbcfgfordatabase,

得到

LOCKLIST1000

MAXLOCKS90

LOCKTIMEOUT45

DLCHKTIME60000

LOCKLIST好像有些小，二话不说讲参数修改为10000后进行观察，错误出现的频率小了，问题还是存在，咬咬呀狠狠心改为30000

呵呵，终于不出现了，我也清闲了一段时间。可是好几景不长大约过了一个月左右的时间，问题又出现了。郁闷ing。

2.利用控制中心查找有问题的SQL.

使用控制中心的监控器可以非常方便的找到是否有死锁，应用程序锁等待数量、时间，锁升级等情况。

3.查看数据库的db2diag.log和db2inst.nfy

通过检查db2inst.nfy发现

006-08-07-16.51.22.475742Instance:db2instNode:000

PID:53740(db2agent(DB)0)TID:1Appid:C0A8003A.KD70.00CAC7083407

datamanagementsqldEscalateLocksProbe:3DatabaseB

ADM5502WTheescalationof"270083"locksontable"OWN.POST_GOODS"to

lockintent"S"wassuccessful.

在POST_GOODS要有170083个锁啊，于是怀疑与POST_GOODS有关的应用有问题了。

4.让开发人员找到对应的SQL一看，我差点晕倒了。Mygod这儿居然没有任何条件。让开发人员根据业务需要增加查询条件。再重新发布应用，测试哈哈,不仅应用程序飞快，并且不在出现[IBM][CLIDriver][DB2/6000]SQL0911N因为死锁或超时，当前事务已被回滚。原因码为"68"。SQLSTATE=40001

或者是

[IBM][CLIDriver][DB2/6000]SQL0911N因为死锁或超时，当前事务已被回滚。原因码为"2"。SQLSTATE=40001

5.修改数据库参数

问题的根本原因找到了，数据库参数也要调整一下，将LOCKLIST修改为20000，太大了也不好！如果一个应用使用的锁资源超过了20000*90，这个应用程序本身肯定有问题了。