IT技术互动交流平台

DB2发生死锁情况时应该怎么处理

作者:whl  来源:网络整理  发布日期:2018-11-22 08:57:00
  相信大家都发现在数据库里的新应用刚刚开始启用的时候,由于对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的死锁情况进行了详细的讲解,文中示范的造成死锁问题的是select引起的,算是比较困难的一种情况,希望对大家有所帮助。

延伸阅读:

Tag标签: DB2死锁  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规