之前為大家介紹了如何DB2 V8數(shù)據(jù)庫系統(tǒng)轉(zhuǎn)移，本文主要為大家用實例講解"如何在DB2 UDB中正確的監(jiān)控死鎖".

但是我們并不能預測什么時候發(fā)生死鎖，所以如果有一個后臺程序能夠一直監(jiān)控數(shù)據(jù)庫的活動，記錄下所有的死鎖事件，這對于數(shù)據(jù)庫管理員來說是非常重要的。DB2 UDB提供了事件監(jiān)控器。通過不遺漏地獲得一段時間內(nèi)所有的數(shù)據(jù)庫事件(在本文中只關(guān)心其中的死鎖事件)，事件監(jiān)控器提供了一種可以分析歷史數(shù)據(jù)(本文的重點)，預測將來趨勢的可能。DB2 UDB同時提供了DB2 Performance Expert (DB2/PE) 或者類似的程序用來生成分析報表，不過這已經(jīng)超出了本文的范疇。

常用術(shù)語

　　鎖是控制應(yīng)用程序并發(fā)的數(shù)據(jù)庫軟件機制，鎖用來防止以下情況的發(fā)生：

1. 丟失以前更新

2. 不可重復讀取

3. 訪問未提交數(shù)據(jù)

　　鎖的模式包括共享鎖和排他鎖，共享鎖允許其他程序讀取已經(jīng)被其他共享鎖占用的資源，所以也叫讀鎖，排他鎖意味著在釋放資源以前其他的應(yīng)用程序無法訪問同一資源，所以也叫寫鎖。此外，DB2 UDB 還提供了不同的鎖級別，不同的應(yīng)用程序可能會要求訪問不同范圍的數(shù)據(jù)，鎖級別有利于充分利用系統(tǒng)資源，提高系統(tǒng)性能。若一個應(yīng)用程序請求一個鎖，而該鎖被另外一個應(yīng)用程序所使用且不能共享，DB2 UDB 就會掛起前一個應(yīng)用程序。鎖升級就是當LOCKLIST (LOCKLIST代表鎖能夠占用的內(nèi)存空間) 耗盡或者一個應(yīng)用程序所擁有的鎖大于MAXLOCKS*LOCKLIST的時候(MAXLOCKS 代表應(yīng)用程序所擁有的鎖占所空間的百分比)，DB2 UDB 就試圖把幾個行級別的鎖合并為一個表級別的鎖，從而釋放鎖空間。雖然鎖升級本身并不耗費多少時間，但是鎖住整個表通常會大大地降低并發(fā)性能。

　　當應(yīng)用程序處于掛起狀態(tài)超過了一段規(guī)定的時間后，DB2 UDB就會自動中止這個應(yīng)用程序，同時會向SQLCA發(fā)送描述性的錯誤信息。當兩個或者更多的應(yīng)用程序都持有另外一個應(yīng)用程序所需資源上的鎖，沒有這些資源，那些應(yīng)用程序都無法繼續(xù)完成其工作的時候，就會發(fā)生死鎖。

　　在DLCHKTIME超時之后，DB2 UDB會中止發(fā)生死鎖的某個應(yīng)用程序(通常為所做工作最少的那個應(yīng)用程序)，這會釋放這個應(yīng)用程序所持有的所有的鎖，并允許別的應(yīng)用程序繼續(xù)工作，DB2 UDB 將向被終止的應(yīng)用程序的SQLCA發(fā)送描述性的錯誤信息。LOCKTIMEOUT 指定一個應(yīng)用程序被允許的鎖等待的時間，這將避免全局的死鎖從而導致整個應(yīng)用崩潰。如果LOCKTIMEOUT 的值為-1，應(yīng)用程序會等待直到該鎖被釋放或者發(fā)生一個死鎖。

事件監(jiān)控器

　　事件監(jiān)控器用來收集當一個數(shù)據(jù)庫事件發(fā)生時所關(guān)聯(lián)的應(yīng)用程序的信息。這里的事件指，連接，死鎖，聲明和事務(wù)。你可以定義你想監(jiān)控的事件類型的監(jiān)控器。比如說，一個死鎖監(jiān)控器就是用來監(jiān)控死鎖的發(fā)生。

　　在DB2 UDB 中存在兩種和死鎖有關(guān)的事件類型：

　　DEADLOCKS

　　記錄簡單的應(yīng)用程序信息。

　　DEADLOCKS WITH DETAILS

　　記錄所有復雜的信息，包括應(yīng)用程序、執(zhí)行語句聲明以及死鎖的詳細信息。但是使用這種事件監(jiān)控器會因為需要得到大量額外的信息而降低系統(tǒng)的性能。
 

如何監(jiān)控死鎖

　　為了詳細說明事件監(jiān)控器在死鎖監(jiān)控中的用途，我引入了一個簡單的死鎖場景來觸發(fā)一個死鎖，在隨后的章節(jié)，我會告訴讀者如何分析監(jiān)控結(jié)果以及根據(jù)結(jié)果來避免死鎖的發(fā)生。

　　這里我們需要至少三個應(yīng)用程序來調(diào)用DB2 CLI，一個用來監(jiān)控死鎖的發(fā)生，另外兩個用來產(chǎn)生死鎖。我們可以使用DB2 UDB 安裝時附帶的SAMPLE數(shù)據(jù)庫。

　　1. 首先建立一個死鎖事件監(jiān)控器

　　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. 用另外兩個應(yīng)用程序來產(chǎn)生一個死鎖

　　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)"

　　現(xiàn)在應(yīng)用程序A就擁有了一個EMPLOYEE表的行級別的排他鎖

　　(注: +c 代表不自動提交SQL語句，DB2 中 autocommit 是缺省設(shè)置，也可以通過 db2 update command options using c off 關(guān)閉該缺省選項。)

　　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')"

　　現(xiàn)在應(yīng)用程序B就擁有了一個PROJECT表的行級別的排他鎖

　　Session A

　　db2 +c "select projname from project"

　　應(yīng)用程序A需要PROJECT表上所有行的共享鎖，但是因為PROJECT表正在被應(yīng)用程序B以排他鎖的形式獨占，這時候應(yīng)用程序1就進入一個鎖等待的狀態(tài)。

　　Session B

　　db2 +c "select firstnme from employee"

　　應(yīng)用程序B也進入一個鎖等待的狀態(tài)。此時就出現(xiàn)了一個死鎖狀態(tài)。

　　3. 兩個本身處于鎖等待并且占有資源的應(yīng)用程序互相等待另外一方所持有的資源，這時候Session A和Session B就出現(xiàn)了死鎖狀態(tài)，這種狀態(tài)一直會延續(xù)直到死鎖檢查器(超出DLCHKTIME時間以后)檢查出一個死鎖并且回滾其中的一個事務(wù)。

　　Session B

　　SQLN0991N 因為死鎖或者超時，當前事務(wù)已經(jīng)被回滾。原因碼為 "2". SQLSTATE=40001這時候死鎖事件監(jiān)控器就會記錄這個死鎖，同時應(yīng)用程序A可以完成他的工作。

　　Session A

　　PROJNAME----------……20 條記錄已選擇

　　Session A

　　db2 connect reset

　　Session B

　　db2 connect reset

　　4. 通過 db2evmon 工具可以獲得死鎖信息的日志，并且把日志文件導入到本地機器的文件系統(tǒng)當中。在下面一節(jié)，我們將詳細分析導出的日志文件。

　　Session Monitordb2 connect resetdb2evmon

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

分析監(jiān)控結(jié)果

　　本節(jié)我們開始詳細分析上一節(jié)產(chǎn)生的監(jiān)控結(jié)果，從監(jiān)控導出的日志文件中，我們可以分析出死鎖發(fā)生的時間，級別，模式以及產(chǎn)生死鎖的SQL語句，從而據(jù)此來進一步地修正可能由程序并發(fā)設(shè)計或者數(shù)據(jù)庫設(shè)計所導致的缺陷。

　　---------------------------------

　　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.01B40608320***ppl 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鎖發(fā)生的表) 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共享鎖，發(fā)生死鎖) ……Text:

　　select name from employee(產(chǎn)生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表上發(fā)生的事件)

　　我們可以分析一下dllog1.txt 文件，來準確定位死鎖發(fā)生的原因，看看5)Deadlocked Connection: 我們可以看出死鎖發(fā)生的表是EMPLOYEE，同時我們也可以判斷出這是一個對于已被排他鎖占有的資源申請共享鎖所導致的死鎖。更加重要的是我們得到了產(chǎn)生死鎖的SQL語句，從上面我們可以推斷出一定存在別的應(yīng)用程序在以獨占鎖的方式占用EMPLOYEE表，這很有可能就是對于EMPLOYEE表的插入或者更新動作造成的。

　　而這最有可能就是插入或者更新事務(wù)時間過長所導致的，導致事務(wù)時間過長的原因大體有兩種，一是來自于并發(fā)程序的設(shè)計和編寫，二是來自于數(shù)據(jù)庫的設(shè)計和數(shù)據(jù)庫參數(shù)的調(diào)整。

　　本節(jié)我們通過仔細地分析事件監(jiān)控器的結(jié)果來推斷出導致死鎖發(fā)生的原因，從而采取有效的措施去避免死鎖的發(fā)生。這些措施包括調(diào)整數(shù)據(jù)庫參數(shù)，或者修改應(yīng)用程序的代碼，或者修改SQL語句甚至是數(shù)據(jù)庫的設(shè)計來提高代碼和SQL語句執(zhí)行的效率。

　　避免死鎖的方法

　　越早地考慮數(shù)據(jù)庫設(shè)計中的并發(fā)性問題，就越可以提高代碼執(zhí)行的效率，降低程序開發(fā)和維護的成本，這里我們提出了一些避免死鎖，提高應(yīng)用程序并發(fā)性的方法。

　　設(shè)置隔離級別，根據(jù)應(yīng)用程序的業(yè)務(wù)邏輯和數(shù)據(jù)完整性需求來決定合適的隔離級別，包括：RR，RS，CS，UR。該決定需要對應(yīng)用程序需求和相關(guān)的業(yè)務(wù)規(guī)則具有基本理解

　　盡量避免鎖升級，正確調(diào)整參數(shù)LOCKLIST, MAXLOCKS

　　SQL0911N返回碼68(LOCKTIMEOUT參數(shù))的原因是鎖等待超時，而SQL0911返回碼2(DLCHKTIME參數(shù))的原因則是因為死鎖被強制回滾，避免這兩種錯誤的方法就是合理設(shè)計數(shù)據(jù)庫和建立合理的索引

　　盡快提交事務(wù)，不要在事務(wù)中加入不必要的執(zhí)行時間過長的代碼，比如大的代碼循環(huán)和遠程調(diào)用，或者一些沒有用處的SELECT語句

　　應(yīng)用程序的框架實現(xiàn)保證一旦發(fā)現(xiàn)SQL錯誤，立刻執(zhí)行回滾事務(wù)，釋放鎖。

　　如果多個應(yīng)用程序訪問同一資源，***以相同的次序訪問。這樣，即使前一個訪問資源的應(yīng)用程序會延遲其他應(yīng)用程序的訪問，也不會導致死鎖的發(fā)生

　　設(shè)定外鍵索引，如果想刪除父表中的行，就需要掃描多個子表中的多行數(shù)據(jù)，這樣就需要占用多個子表的鎖，我們可以通過在外鍵上建立索引來減少掃描子表的行數(shù)，否則若不建立索引，如果從父表中刪除一行的時候，就需要掃描整個子表。

　　總結(jié)

　　在我門完成這個例子的實際過程中，大家可以看到不同DB2工具(DBC CLI, SQL, DB2EVMON)的使用實例，并且可以學會如何逐步地利用死鎖事件監(jiān)控器來監(jiān)控死鎖的發(fā)生，***我門掌握的內(nèi)容是如何分析那些從死鎖監(jiān)控器得來的結(jié)果，以及采用相應(yīng)的措施來避免死鎖的發(fā)生。如何在DB2 UDB中正確的監(jiān)控死鎖對有的人來說可能是比較難克服的一個問題，希望本篇文章能夠幫到大家解決工作中監(jiān)控死鎖的問題。

【編輯推薦】

1. 對DB2 UDB v8.1 以及其數(shù)據(jù)庫進行調(diào)優(yōu)的***方案
2. IBM DB2 UDB 在線備份與恢復***演習！
3. 在DB2 UDB中使用SQL過程語言來操作觸發(fā)器