常用术语
锁是控制应用程序并发的数据库软件机制，锁用来防止以下情况的发生：
1． 丢失以前更新
2． 不可重复读取
3． 访问未提交数据
锁的模式包括共享锁和排他锁，共享锁允许其他程序读取已经被其他共享锁占用的资源，所以也叫读锁，排他锁意味着在释放资源以前其他的应用程序无法访问同一资源，所以也叫写锁。此外，DB2 UDB 还提供了不同的锁级别，不同的应用程序可能会要求访问不同范围的数据，锁级别有利于充分利用系统资源，提高系统性能。若一个应用程序请求一个锁，而该锁被另外一个应用程序所使用且不能共享，DB2 UDB 就会挂起前一个应用程序。锁升级就是当LOCKLIST (LOCKLIST代表锁能够占用的内存空间) 耗尽或者一个应用程序所拥有的锁大于MAXLOCKS*LOCKLIST的时候（MAXLOCKS 代表应用程序所拥有的锁占所空间的百分比），DB2 UDB 就试图把几个行级别的锁合并为一个表级别的锁，从而释放锁空间。虽然锁升级本身并不耗费多少时间，但是锁住整个表通常会大大地降低并发性能。
当应用程序处于挂起状态超过了一段规定的时间后，DB2 UDB就会自动中止这个应用程序，同时会向SQLCA发送描述性的错误信息。当两个或者更多的应用程序都持有另外一个应用程序所需资源上的锁，没有这些资源，那些应用程序都无法继续完成其工作的时候，就会发生死锁。
在DLCHKTIME超时之后，DB2 UDB会中止发生死锁的某个应用程序（通常为所做工作最少的那个应用程序），这会释放这个应用程序所持有的所有的锁，并允许别的应用程序继续工作，DB2 UDB 将向被终止的应用程序的SQLCA发送描述性的错误信息。LOCKTIMEOUT 指定一个应用程序被允许的锁等待的时间，这将避免全局的死锁从而导致整个应用崩溃。如果LOCKTIMEOUT 的值为-1，应用程序会等待直到该锁被释放或者发生一个死锁。

事件监控器
事件监控器用来收集当一个数据库事件发生时所关联的应用程序的信息。这里的事件指，连接，死锁，声明和事务。你可以定义你想监控的事件类型的监控器。比如说，一个死锁监控器就是用来监控死锁的发生。
在DB2 UDB 中存在两种和死锁有关的事件类型：
DEADLOCKS

记录简单的应用程序信息。 
DEADLOCKS WITH DETAILS
记录所有复杂的信息，包括应用程序、执行语句声明以及死锁的详细信息。但是使用这种事件监控器会因为需要得到大量额外的信息而降低系统的性能。 

如何监控死锁
为了详细说明事件监控器在死锁监控中的用途，我引入了一个简单的死锁场景来触发一个死锁，在随后的章节，我会告诉读者如何分析监控结果以及根据结果来避免死锁的发生。
这里我们需要至少三个应用程序来调用DB2 CLI，一个用来监控死锁的发生，另外两个用来产生死锁。我们可以使用DB2 UDB 安装时附带的SAMPLE数据库。
1． 首先建立一个死锁事件监控器

 --------------------------------------------------------------------------                            EVENT LOG HEADER  Event Monitor name: DLMON  Server Product ID: SQL08022……  Server instance name: DB2----------------------------------------------------------------------------------------------------------------------------------------------------  Database Name: SAMPLE    Database Path: C:\DB2\NODE0000\SQL00001\ ……--------------------------------------------------------------------------3) Deadlock Event ...  Deadlock ID:   1 ……4) Connection Header Event ...  Appl Handle: 949 ……5) Deadlocked Connection ...  Deadlock ID:   1  Participant no.: 2  Participant no. holding the lock: 1  Appl Id: G9B56A72.HE13.01B406083205  Appl Seq number: 0001  Appl Id of connection holding the lock: G9B56A72.HD13.02CE06083152 ……  Deadlock detection time: 2006-01-06 16:34:27.327582  Table of lock waited on      : EMPLOYEE (A锁发生的表)  Schema of lock waited on     : JT        Tablespace of lock waited on : USERSPACE1  Type of lock: Row （A锁级别为行锁）  Mode of lock: X   - Exclusive （A锁模式为排他锁）  Mode application requested on lock: NS - Share (and Next Key Share) （在A排他锁上要求B共享锁，发生死锁） ……Text     : select name from employee（产生B共享锁的SQL语句）  List of Locks: （当前所有锁的列表）  ……      Lock Name                   : 0x020005000D0000000000000052      Lock Attributes             : 0x00000008      Release Flags               : 0x40000000      Lock Count                  : 1      Hold Count                  : 0      Lock Object Name            : 13      Object Type                 : Row      Tablespace Name             : USERSPACE1      Table Schema                : JT            Table Name                  : PROJECT      Mode                        : X   - Exclusive    （在PROJECT表上有一个排他锁）……      Lock Name                   : 0x02000300000000000000000054      Lock Attributes             : 0x00000000      Release Flags               : 0x00000001      Lock Count                  : 1      Hold Count                  : 0      Lock Object Name            : 3      Object Type                 : Table      Tablespace Name             : USERSPACE1      Table Schema                : JT            Table Name                  : EMPLOYEE      Mode                        : IS  - Intent Share  （在EMPLOYEE表上有一个共享锁）  Locks Held: 6  Locks in List: 6……9) Table Event ...  Table schema: JT        Table name: EMPLOYEE  Record is the result of a flush: FALSE  Table type: User  Data object pages: 1……  Rows read: 35  Rows written: 1 ……  Tablespace id: 2  Table event timestamp: 2006-01-06 16:37:28.972501 （记录EMPLOYEE表上发生的事件)