解决“SQL0911N 因为死锁或超时 ”的心得体会
最近应用程序中老是报：
[IBM][CLI Driver][DB2/6000] SQL0911N 因为死锁或超时，当前事务已被回滚。原因码为 "68"。 SQLSTATE=40001
或者是
[IBM][CLI Driver][DB2/6000] SQL0911N 因为死锁或超时，当前事务已被回滚。原因码为 "2"。 SQLSTATE=40001
以下是我查找原因和解决问题的方法和步骤，与大家共享。
1.调整数据库参数 LOCKLIST,MAXLOCKS,LOCKTIMEOUT,DLCHKTIME
参数说明：
LOCKLIST就是锁资资源大小，实际上就是以KB为单位的内存。
MAXLOCKS是一个应用程序实际使用的锁资源所占用的LOCKLIST的比例，当超过这个比例时，锁就会产生升级。
LOCKTIMEOUT锁等待超时时间，以秒为单位。当应用程序提出所资源申请时，如果超过了这个时间而没有得到就会产生锁定超时。
DLCHKTIME是检测死锁的时间间隔，以毫秒为单位。
增大LOCKLIST.
首先查看数据库参数 get db cfg for database,
得到
LOCKLIST 1000
MAXLOCKS 90
LOCKTIMEOUT 45
DLCHKTIME 60000
LOCKLIST好像有些小，二话不说讲参数修改为10000后进行观察，错误出现的频率小了，问题还是存在，咬咬呀狠狠心改为30000
呵呵，终于不出现了，我也清闲了一段时间。可是好几景不长大约过了一个月左右的时间，问题又出现了。郁闷ing。
2.利用控制中心查找有问题的SQL.
使用控制中心的监控器可以非常方便的找到是否有死锁，应用程序锁等待数量、时间，锁升级等情况。
3.查看数据库的db2diag.log和db2inst.nfy
通过检查db2inst.nfy发现
006-08-07-16.51.22.475742 Instance:db2inst Node:000
PID:53740(db2agent (DB) 0) TID:1 Appid:C0A8003A.KD70.00CAC7083407
data management sqldEscalateLocks Probe:3 Database
B
ADM5502W The escalation of "270083" locks on table "OWN .POST_GOODS" to
lock intent "S" was successful.
在POST_GOODS要有170083个锁啊，于是怀疑与POST_GOODS有关的应用有问题了。
4.让开发人员找到对应的SQL一看，我差点晕倒了。My god这儿居然没有任何条件。让开发人员根据业务需要增加查询条件。再重新发布应用，测试哈哈,不仅应用程序飞快，并且不在出现[IBM][CLI Driver][DB2/6000] SQL0911N 因为死锁或超时，当前事务已被回滚。原因码为 "68"。 SQLSTATE=40001
或者是
[IBM][CLI Driver][DB2/6000] SQL0911N 因为死锁或超时，当前事务已被回滚。原因码为 "2"。 SQLSTATE=40001
5.修改数据库参数
问题的根本原因找到了，数据库参数也要调整一下， 将LOCKLIST修改为20000，太大了也不好！如果一个应用使用的锁资源超过了20000*90，这个应用程序本身肯定有问题了
