常用術語
鎖是控制應用程序并發的數據庫軟件機制，鎖用來防止以下情況的發生：
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表上發生的事件)