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

　　为了详细说明事件监控器在死锁监控中的用途，我引入了一个简单的死锁场景来触发一个死锁，在随后的章节，我会告诉读者如何分析监控结果以及根据结果来避免死锁的发生。

　　这里我们需要至少三个应用程序来调用DB2 CLI，一个用来监控死锁的发生，另外两个用来产生死锁。我们可以使用DB2 UDB 安装时附带的SAMPLE数据库。

　　1. 首先建立一个死锁事件监控器

　　Session Monitor

　　db2 connect to sampledb2 "create event monitor

　　dlmon for tables, deadlocks with details write

　　to file 'C:\dlmon'"mkdir C:\dlmondb2 "

　　set event monitor dlmon state 1"

　　2. 用另外两个应用程序来产生一个死锁

　　Session A

　　db2 connect to sampledb2 +c "insert into employee values('000350', 'Truman', 'I', 'Jiang',

　　'B00', '5892','1999-02-21', 'Engineer', 19, 'M',

　　'1978-06-17', 60000, 2000, 6000)"

　　现在应用程序A就拥有了一个EMPLOYEE表的行级别的排他锁

　　(注: +c 代表不自动提交SQL语句，DB2 中 autocommit 是缺省设置，也可以通过 db2 update command options using c off 关闭该缺省选项。)

　　Session B

　　db2 connect to sampledb2 +c "insert into project

　　values('AD3300', 'Dead Lock Monitor', 'B00', '000350',

　　7.00, '1982-07-21', '1983-02-03', 'AD3111')"

　　现在应用程序B就拥有了一个PROJECT表的行级别的排他锁

　　Session A

　　db2 +c "select projname from project"

　　应用程序A需要PROJECT表上所有行的共享锁，但是因为PROJECT表正在被应用程序B以排他锁的形式独占，这时候应用程序1就进入一个锁等待的状态。

　　Session B

　　db2 +c "select firstnme from employee"

　　应用程序B也进入一个锁等待的状态。此时就出现了一个死锁状态。

　　3. 两个本身处于锁等待并且占有资源的应用程序互相等待另外一方所持有的资源，这时候Session A和Session B就出现了死锁状态，这种状态一直会延续直到死锁检查器(超出DLCHKTIME时间以后)检查出一个死锁并且回滚其中的一个事务。

　　Session B

　　SQLN0991N 因为死锁或者超时，当前事务已经被回滚。原因码为 "2". SQLSTATE=40001这时候死锁事件监控器就会记录这个死锁，同时应用程序A可以完成他的工作。

　　Session A

　　PROJNAME----------……20 条记录已选择

　　Session A

　　db2 connect reset

　　Session B

　　db2 connect reset

　　4. 通过 db2evmon 工具可以获得死锁信息的日志，并且把日志文件导入到本地机器的文件系统当中。在下面一节，我们将详细分析导出的日志文件。

　　Session Monitordb2 connect resetdb2evmon

　　-path c:\dlmon > c:\dlmon\dllog1.txt