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

你可能感兴趣的:(sql)