在众多数据库当中，DB2数据库是大家很少见到的，因此很多关于DB2数据库的问题，大家都不清楚。就好比如何解决DB2数据库死锁问题的？下面我们将通过解决DB2数据库死锁过程记录来为大家详细介绍解决这个问题的方法。具体包括8个阶段，相信通过这8个阶段的学习，您就知道如何解决这个问题了。

大家可以想象，在没有快照等功能下，分析死锁就只能靠分析代码了。但是这个处理非常复杂，单凭分析代码，没有任何头绪。

　　阶段1：我们怀疑是数据量的原因

由于生产环境的数据量特别大，这个处理还有很多其他表的处理。所以我们怀疑是不是大数据量导致系统负荷过高，导致了死锁？

于是我们取得了发生死锁时CPU，硬盘，网络等等负载信息。没有找到任何线索。

　　阶段2：做一个测试程序，在测试环境中用多线程模拟多用户去做这个处理。

为了能够在开发环境再现出这个死锁，我们做了一个多线程的测试程序，模拟多用户运行。可惜，还是没有再现出来。

　　阶段3：分析测试环境数据库和产品环境数据库的差异

此时我们怀疑还是数据量导致的问题。于是我们尽可能的将开发环境的数据弄得和产品环境一样多。之后在运行测试，还是没有再现出来。

　　阶段4：分析用户的操作log

没有任何办法的情况下，我们只好分析用户的操作log，希望从中找到一点线索。功夫不负有心人，我们发现，当两个人同时；

进行这个操作的时候，基本都会发生死锁。所以，我们判断还是两个人同时操作导致的问题。但是，为什么开发环境上模拟了。

很多人的操作，却没有发生死锁呢？

　　阶段5：发现数据库设置的问题

我们又修改了测试程序，将模拟的用户数量提高，但是很不幸，仍然没有再现这个问题。此时我们注意到了：是不是开发环境的；

数据库设置和产品环境的数据库设置不同？我们对比了一下两个数据库的设置：发现好多参数不同。但是我们仅仅关注了和锁有关的设置，也就是包含 LOCK关键字的设置。

　　阶段6：将测试环境数据库和产品环境数据库的设置保持一致

我们将所有和lock有关的设置都改成了和产品环境一直。但是仍然没有再现这个死锁。终于，一个人发现，"cur_commit"这个设置不同。于是查询文档，发现了 cur_commit的特点。

当cur_commit = false的时候，下列情况会造成死锁：

线程1插入数据A，然后线程2插入数据B。

　　在线程2还没有提交事物之前，线程1查询数据A，就会造成死锁了。

开发环境中，cur_commit = true，所以我们一直也模拟不出来这个现象。

于是，我们把cur_commit也改成了 false。

　　阶段7：使用测试程序去模拟

我们修改了测试程序，模拟上面两个线程的操作，成功地再现了这个死锁。错误的log信息和产品环境上也是一致的。

　　阶段8：使用画面操作去模拟

然后我们修改了程序，使用画面去操作，也成功地再现了这个死锁。

　　解决方案：

解决方案很简单，就是把查询语句中的条件加为索引，就不会出现死锁了。由于这个表数据量不大，所以性能几乎没有任何影响。

以上就是关于如何解决DB2数据库死锁问题的全部内容，想了解更多关于DB2数据库的信息，请继续关注中培伟业。