DB2 死锁问题？

楼上的牛,解释的很清晰收起

发表一下自己的看法:
1):deadlock是死锁,是当前运行事务和其他运行事务发生了资源争用, 两个事务都不能释放对方需要的资源.应该是这样吧.
2):locktimeout是当前事务1 等待其他事务 如 事务2 释放 本事务需要的资源的 等待时间吧.在这个时间间隔内 事务2 没有释放 事务1 所需要的资源, 则 事务1 等待超时, 事务1 应该就失败了.收起

deadlock 和lock timeout的概念没搞清晰收起

db2 的锁问题是比较常见的，下面是一些建议

DB2中关于并发控制（锁）的建议

1．正确调整locklist，maxlocks，dlchktime和locktimeout等和锁有关的数据库配置参数（locktimeout最好不要等于-1）。如果锁内存不足会报SQL0912错误而影响并发。

2．写出高效而简洁的SQL语句（非常重要）。

3．在业务逻辑处理完后尽可能快速commit释放锁。

4．对引起锁等待（SQL0911返回码68）和死锁（SQL0911返回码2）的SQL语句创建最合理的索引（非常重要，尽量创建复合索引和包含索引）。

5．使用 altER TABLE 语句的 LOCKSIZE 参数控制如何在持久基础上对某个特定表进行锁定。检查syscat.tables中locksize字段，尽量在符合业务逻辑的情况下，每个表中该字段为"R"（行级锁）。

6．根据业务逻辑使用正确的隔离级别（RR，RS，CS和UR）。

7．当执行大量更新时，更新之前，在整个事务期间锁定整个表（使用 SQL LOCK TABLE 语句）。这只使用了一把锁从而防止其它事务进行这些更新，但是对于其他用户它的确减少了数据并发性。收起

老周说的是根本原因，还要要在应用程序端先想想办法。收起

之前也被死锁困扰过，最后是通过调大locklist，修改应用解决的。
个人认为：造成大量死锁最经常的原因就是没有建合适的索引，locklist太小，应用写得有问题。收起

最根本的应该是改程序，把长事务改成短事务。收起

关于死锁，我再说几点我的经验吧。
1、关于 LOCKLIST：在内存允许的情况下，尽量大一些吧，默认值实在太小了。如果该参数值太小，会造成频繁的锁升级（因为锁空间不够用，就会把行锁升级为表锁），这会对系统性能造成巨大影响。
2、关于LOCKTIMEOUT：，默认值是-1，即无限等待，这会使应用程序出现无限等待，从而影响性能，所以强烈建议更改为一个指定值，例如15秒。
3、关于DB2自动锁检测的参数：保持默认值即可，改参数值太小也会对性能造成影响。
DB2本身对于锁的机制已经很成熟了，除非特殊情况，否则不需要人工干预。收起

locklist 是数据库 的 锁 能 使用 的 内存空间的最大值,增大这个值, 一定程度上 可以在 死锁 发生的时候, 不影响应用并发数.
locktimeout 是 只是应用程序 锁等待(等待其他锁释放资源) 的 超时时间.
dlchktime 是 检查 死锁 的 时间间隔.
个人理解 是 dlchktime 越小,即 检查死锁的 频率越快, 死锁释放的就越快.
但dlchktime太小了, 会不会 把 进行锁等待 的 应用 给 干掉 呀!! 求教呀!收起

楼上的同志们回答精辟收起