解决“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，这个应用程序本身肯定有问题了