实例讲解如何在DB2 UDB中正确的监控死锁

核心提示： 我们可以分析一下dllog1.txt 文件，来准确定位死锁发生的原因，实例讲解如何在DB2 UDB中正确的监控死锁(5)，看看5）Deadlocked Connection: 我们可以看出死锁发生的表是EMPLOYEE，同时我们也可以判定出这是一个对于已被排他锁占有的资源申请共享锁所导致的

我们可以分析一下dllog1.txt 文件，来准确定位死锁发生的原因，看看5）Deadlocked Connection: 我们可以看出死锁发生的表是EMPLOYEE，同时我们也可以判定出这是一个对于已被排他锁占有的资源申请共享锁所导致的死锁。更加重要的是我们得到了产生死锁的SQL语句，从上面我们可以推断出一定存在别的应用程序在以独占锁的方式占用EMPLOYEE表，这很有可能就是对于EMPLOYEE表的插入或者更新动作造成的。

而这最有可能就是插入或者更新事务时间过长所导致的，导致事务时间过长的原因大体有两种，一是来自于并发程序的设计和编写，二是来自于数据库的设计和数据库参数的调整。

本节我们通过仔细地分析事件监控器的结果来推断出导致死锁发生的原因，从而采取有效的措施去避免死锁的发生。这些措施包括调整数据库参数，或者修改应用程序的代码，或者修改SQL语句甚至是数据库的设计来提高代码和SQL语句执行的效率。

避免死锁的方法

越早地考虑数据库设计中的并发性问题，就越可以提高代码执行的效率，降低程序开发和维护的成本，这里我们提出了一些避免死锁，提高应用程序并发性的方法。

设置隔离级别，根据应用程序的业务逻辑和数据完整性需求来决定合适的隔离级别，包括：RR，RS，CS，UR。该决定需要对应用程序需求和相关的业务规则具有基本理解

尽量避免锁升级，正确调整参数LOCKLIST, MAXLOCKS

SQL0911N返回码68（LOCKTIMEOUT参数）的原因是锁等待超时，而SQL0911返回码2（DLCHKTIME参数）的原因则是因为死锁被强制回滚，避免这两种错误的方法就是合理设计数据库和建立合理的索引

尽快提交事务，不要在事务中加入不必要的执行时间过长的代码，比如大的代码循环和远程调用，或者一些没有用处的SELECT语句

应用程序的框架实现保证一旦发现SQL错误，马上执行回滚事务，释放锁。

假如多个应用程序访问同一资源，最好以相同的次序访问。这样，即使前一个访问资源的应用程序会延迟其他应用程序的访问，也不会导致死锁的发生

设定外键索引，假如想删除父表中的行，就需要扫描多个子表中的多行数据，这样就需要占用多个子表的锁，我们可以通过在外键上建立索引来减少扫描子表的行数，否则若不建立索引，假如从父表中删除一行的时候，就需要扫描整个子表。

总结

在我门完成这个例子的实际过程中，大家可以看到不同DB2工具（DBC CLI, SQL, DB2EVMON）的使用实例，并且可以学会如何逐步地利用死锁事件监控器来监控死锁的发生，最后我门把握的内容是如何分析那些从死锁监控器得来的结果，以及采用相应的措施来避免死锁的发生。