在众多数据库当中，虽然DB2数据库很少见，但是应用却十分广泛。DB2的主要操作环境是UNIX，Linux，
IBMi，z /OS和Windows服务器版本。DB2的功能也相对强大，因为它具有完整的查询优化器，
并且其外部连接提高了查询性能并支持多个Task并行查询。同时DB2还具有良好的网络支持功能，
每个子系统可以连接成千上万的分布式用户，并且可以同时激活数千个活动线程，
这特别适合于大型分布式应用程序系统。那么DB2数据库管理系统是如何解决死锁的？
DB2数据库管理系统是如何解决死锁的？
生产环境里使用的数据库是DB2。但是近期频繁出现一个奇怪的死锁现象：某一个select sql 语句总是会出现死锁。
按照以往的经验，通常都是update/delete之类的更新sql语句会出现死锁的问题。而且这个 select sql
语句是一个很普通的sql，没有任何大数据量的处理。
分析这个死锁，有很多难以处理的地方。
1、因为生产环境数据量大，我们无法把生产环境中关联表的数据导入到测试环境。也就是说，无法模拟数据量。
2、没有任何log输出。因为生产环境的log输出级别是ERROR。
3、无法在生产环境进行测试，因为客户不允许。
4、生产环境的数据库无法开启快照等功能。因为会影响性能。
大家可以想象，在没有快照等功能下，分析死锁就只能靠分析代码了。但是这个处理非常复杂，单凭分析代码，没有任何头绪。
阶段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技术原理及应用课程 百度网盘 课程大小：0.00字节 |
提取码：**** （购买后可见） |
下载 |
