實(shí)例講解如何在DB2 UDB中正確的監(jiān)控死鎖
之前為大家介紹了如何DB2 V8數(shù)據(jù)庫系統(tǒng)轉(zhuǎn)移，本文主要為大家用實(shí)例講解"如何在DB2 UDB中正確的監(jiān)控死鎖".
但是我們并不能預(yù)測什么時(shí)候發(fā)生死鎖，所以如果有一個(gè)后臺(tái)程序能夠一直監(jiān)控?cái)?shù)據(jù)庫的活動(dòng)，記錄下所有的死鎖事件，這對(duì)于數(shù)據(jù)庫管理員來說是非常重要的。DB2 UDB提供了事件監(jiān)控器。通過不遺漏地獲得一段時(shí)間內(nèi)所有的數(shù)據(jù)庫事件(在本文中只關(guān)心其中的死鎖事件)，事件監(jiān)控器提供了一種可以分析歷史數(shù)據(jù)(本文的重點(diǎn))，預(yù)測將來趨勢的可能。DB2 UDB同時(shí)提供了DB2 Performance Expert (DB2/PE) 或者類似的程序用來生成分析報(bào)表，不過這已經(jīng)超出了本文的范疇。
常用術(shù)語
鎖是控制應(yīng)用程序并發(fā)的數(shù)據(jù)庫軟件機(jī)制，鎖用來防止以下情況的發(fā)生：
1. 丟失以前更新
2. 不可重復(fù)讀取
3. 訪問未提交數(shù)據(jù)
鎖的模式包括共享鎖和排他鎖，共享鎖允許其他程序讀取已經(jīng)被其他共享鎖占用的資源，所以也叫讀鎖，排他鎖意味著在釋放資源以前其他的應(yīng)用程序無法訪問同一資源，所以也叫寫鎖。此外，DB2 UDB 還提供了不同的鎖級(jí)別，不同的應(yīng)用程序可能會(huì)要求訪問不同范圍的數(shù)據(jù)，鎖級(jí)別有利于充分利用系統(tǒng)資源，提高系統(tǒng)性能。若一個(gè)應(yīng)用程序請(qǐng)求一個(gè)鎖，而該鎖被另外一個(gè)應(yīng)用程序所使用且不能共享，DB2 UDB 就會(huì)掛起前一個(gè)應(yīng)用程序。鎖升級(jí)就是當(dāng)LOCKLIST (LOCKLIST代表鎖能夠占用的內(nèi)存空間) 耗盡或者一個(gè)應(yīng)用程序所擁有的鎖大于MAXLOCKS*LOCKLIST的時(shí)候(MAXLOCKS 代表應(yīng)用程序所擁有的鎖占所空間的百分比)，DB2 UDB 就試圖把幾個(gè)行級(jí)別的鎖合并為一個(gè)表級(jí)別的鎖，從而釋放鎖空間。雖然鎖升級(jí)本身并不耗費(fèi)多少時(shí)間，但是鎖住整個(gè)表通常會(huì)大大地降低并發(fā)性能。
當(dāng)應(yīng)用程序處于掛起狀態(tài)超過了一段規(guī)定的時(shí)間后，DB2 UDB就會(huì)自動(dòng)中止這個(gè)應(yīng)用程序，同時(shí)會(huì)向SQLCA發(fā)送描述性的錯(cuò)誤信息。當(dāng)兩個(gè)或者更多的應(yīng)用程序都持有另外一個(gè)應(yīng)用程序所需資源上的鎖，沒有這些資源，那些應(yīng)用程序都無法繼續(xù)完成其工作的時(shí)候，就會(huì)發(fā)生死鎖。
在DLCHKTIME超時(shí)之后，DB2 UDB會(huì)中止發(fā)生死鎖的某個(gè)應(yīng)用程序(通常為所做工作最少的那個(gè)應(yīng)用程序)，這會(huì)釋放這個(gè)應(yīng)用程序所持有的所有的鎖，并允許別的應(yīng)用程序繼續(xù)工作，DB2 UDB 將向被終止的應(yīng)用程序的SQLCA發(fā)送描述性的錯(cuò)誤信息。LOCKTIMEOUT 指定一個(gè)應(yīng)用程序被允許的鎖等待的時(shí)間，這將避免全局的死鎖從而導(dǎo)致整個(gè)應(yīng)用崩潰。如果LOCKTIMEOUT 的值為-1，應(yīng)用程序會(huì)等待直到該鎖被釋放或者發(fā)生一個(gè)死鎖。
事件監(jiān)控器
事件監(jiān)控器用來收集當(dāng)一個(gè)數(shù)據(jù)庫事件發(fā)生時(shí)所關(guān)聯(lián)的應(yīng)用程序的信息。這里的事件指，連接，死鎖，聲明和事務(wù)。你可以定義你想監(jiān)控的事件類型的監(jiān)控器。比如說，一個(gè)死鎖監(jiān)控器就是用來監(jiān)控死鎖的發(fā)生。
在DB2 UDB 中存在兩種和死鎖有關(guān)的事件類型：
DEADLOCKS
記錄簡單的應(yīng)用程序信息。
DEADLOCKS WITH DETAILS
記錄所有復(fù)雜的信息，包括應(yīng)用程序、執(zhí)行語句聲明以及死鎖的詳細(xì)信息。但是使用這種事件監(jiān)控器會(huì)因?yàn)樾枰玫酱罅款~外的信息而降低系統(tǒng)的性能。
如何監(jiān)控死鎖
為了詳細(xì)說明事件監(jiān)控器在死鎖監(jiān)控中的用途，我引入了一個(gè)簡單的死鎖場景來觸發(fā)一個(gè)死鎖，在隨后的章節(jié)，我會(huì)告訴讀者如何分析監(jiān)控結(jié)果以及根據(jù)結(jié)果來避免死鎖的發(fā)生。
這里我們需要至少三個(gè)應(yīng)用程序來調(diào)用DB2 CLI，一個(gè)用來監(jiān)控死鎖的發(fā)生，另外兩個(gè)用來產(chǎn)生死鎖。我們可以使用DB2 UDB 安裝時(shí)附帶的SAMPLE數(shù)據(jù)庫。
1. 首先建立一個(gè)死鎖事件監(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. 用另外兩個(gè)應(yīng)用程序來產(chǎn)生一個(gè)死鎖
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就擁有了一個(gè)EMPLOYEE表的行級(jí)別的排他鎖
(注: +c 代表不自動(dòng)提交SQL語句，DB2 中 autocommit 是缺省設(shè)置，也可以通過 db2 update command options using c off 關(guān)閉該缺省選項(xiàng)。)
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就擁有了一個(gè)PROJECT表的行級(jí)別的排他鎖
Session A
db2 +c "select projname from project"
應(yīng)用程序A需要PROJECT表上所有行的共享鎖，但是因?yàn)镻ROJECT表正在被應(yīng)用程序B以排他鎖的形式獨(dú)占，這時(shí)候應(yīng)用程序1就進(jìn)入一個(gè)鎖等待的狀態(tài)。
Session B
db2 +c "select firstnme from employee"
應(yīng)用程序B也進(jìn)入一個(gè)鎖等待的狀態(tài)。此時(shí)就出現(xiàn)了一個(gè)死鎖狀態(tài)。
3. 兩個(gè)本身處于鎖等待并且占有資源的應(yīng)用程序互相等待另外一方所持有的資源，這時(shí)候Session A和Session B就出現(xiàn)了死鎖狀態(tài)，這種狀態(tài)一直會(huì)延續(xù)直到死鎖檢查器(超出DLCHKTIME時(shí)間以后)檢查出一個(gè)死鎖并且回滾其中的一個(gè)事務(wù)。
Session B
SQLN0991N 因?yàn)樗梨i或者超時(shí)，當(dāng)前事務(wù)已經(jīng)被回滾。原因碼為 "2". SQLSTATE=40001這時(shí)候死鎖事件監(jiān)控器就會(huì)記錄這個(gè)死鎖，同時(shí)應(yīng)用程序A可以完成他的工作。
Session A
PROJNAME----------……20 條記錄已選擇
Session A
db2 connect reset
Session B
db2 connect reset
4. 通過 db2evmon 工具可以獲得死鎖信息的日志，并且把日志文件導(dǎo)入到本地機(jī)器的文件系統(tǒng)當(dāng)中。在下面一節(jié)，我們將詳細(xì)分析導(dǎo)出的日志文件。
Session Monitordb2 connect resetdb2evmon
-path c:\dlmon > c:\dlmon\dllog1.txt
分析監(jiān)控結(jié)果
本節(jié)我們開始詳細(xì)分析上一節(jié)產(chǎn)生的監(jiān)控結(jié)果，從監(jiān)控導(dǎo)出的日志文件中，我們可以分析出死鎖發(fā)生的時(shí)間，級(jí)別，模式以及產(chǎn)生死鎖的SQL語句，從而據(jù)此來進(jìn)一步地修正可能由程序并發(fā)設(shè)計(jì)或者數(shù)據(jù)庫設(shè)計(jì)所導(dǎo)致的缺陷。
---------------------------------
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鎖級(jí)別為行鎖) 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: (當(dāng)前所有鎖的列表)…… 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表上有一個(gè)排他鎖)…… 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表上有一個(gè)共享鎖)
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 文件，來準(zhǔn)確定位死鎖發(fā)生的原因，看看5)Deadlocked Connection: 我們可以看出死鎖發(fā)生的表是EMPLOYEE，同時(shí)我們也可以判斷出這是一個(gè)對(duì)于已被排他鎖占有的資源申請(qǐng)共享鎖所導(dǎo)致的死鎖。更加重要的是我們得到了產(chǎn)生死鎖的SQL語句，從上面我們可以推斷出一定存在別的應(yīng)用程序在以獨(dú)占鎖的方式占用EMPLOYEE表，這很有可能就是對(duì)于EMPLOYEE表的插入或者更新動(dòng)作造成的。
而這最有可能就是插入或者更新事務(wù)時(shí)間過長所導(dǎo)致的，導(dǎo)致事務(wù)時(shí)間過長的原因大體有兩種，一是來自于并發(fā)程序的設(shè)計(jì)和編寫，二是來自于數(shù)據(jù)庫的設(shè)計(jì)和數(shù)據(jù)庫參數(shù)的調(diào)整。
本節(jié)我們通過仔細(xì)地分析事件監(jiān)控器的結(jié)果來推斷出導(dǎo)致死鎖發(fā)生的原因，從而采取有效的措施去避免死鎖的發(fā)生。這些措施包括調(diào)整數(shù)據(jù)庫參數(shù)，或者修改應(yīng)用程序的代碼，或者修改SQL語句甚至是數(shù)據(jù)庫的設(shè)計(jì)來提高代碼和SQL語句執(zhí)行的效率。
避免死鎖的方法
越早地考慮數(shù)據(jù)庫設(shè)計(jì)中的并發(fā)性問題，就越可以提高代碼執(zhí)行的效率，降低程序開發(fā)和維護(hù)的成本，這里我們提出了一些避免死鎖，提高應(yīng)用程序并發(fā)性的方法。
設(shè)置隔離級(jí)別，根據(jù)應(yīng)用程序的業(yè)務(wù)邏輯和數(shù)據(jù)完整性需求來決定合適的隔離級(jí)別，包括：RR，RS，CS，UR。該決定需要對(duì)應(yīng)用程序需求和相關(guān)的業(yè)務(wù)規(guī)則具有基本理解
盡量避免鎖升級(jí)，正確調(diào)整參數(shù)LOCKLIST, MAXLOCKS
SQL0911N返回碼68(LOCKTIMEOUT參數(shù))的原因是鎖等待超時(shí)，而SQL0911返回碼2(DLCHKTIME參數(shù))的原因則是因?yàn)樗梨i被強(qiáng)制回滾，避免這兩種錯(cuò)誤的方法就是合理設(shè)計(jì)數(shù)據(jù)庫和建立合理的索引
盡快提交事務(wù)，不要在事務(wù)中加入不必要的執(zhí)行時(shí)間過長的代碼，比如大的代碼循環(huán)和遠(yuǎn)程調(diào)用，或者一些沒有用處的SELECT語句
應(yīng)用程序的框架實(shí)現(xiàn)保證一旦發(fā)現(xiàn)SQL錯(cuò)誤，立刻執(zhí)行回滾事務(wù)，釋放鎖。
如果多個(gè)應(yīng)用程序訪問同一資源，***以相同的次序訪問。這樣，即使前一個(gè)訪問資源的應(yīng)用程序會(huì)延遲其他應(yīng)用程序的訪問，也不會(huì)導(dǎo)致死鎖的發(fā)生
設(shè)定外鍵索引，如果想刪除父表中的行，就需要掃描多個(gè)子表中的多行數(shù)據(jù)，這樣就需要占用多個(gè)子表的鎖，我們可以通過在外鍵上建立索引來減少掃描子表的行數(shù)，否則若不建立索引，如果從父表中刪除一行的時(shí)候，就需要掃描整個(gè)子表。
總結(jié)
在我門完成這個(gè)例子的實(shí)際過程中，大家可以看到不同DB2工具(DBC CLI, SQL, DB2EVMON)的使用實(shí)例，并且可以學(xué)會(huì)如何逐步地利用死鎖事件監(jiān)控器來監(jiān)控死鎖的發(fā)生，***我門掌握的內(nèi)容是如何分析那些從死鎖監(jiān)控器得來的結(jié)果，以及采用相應(yīng)的措施來避免死鎖的發(fā)生。如何在DB2 UDB中正確的監(jiān)控死鎖對(duì)有的人來說可能是比較難克服的一個(gè)問題，希望本篇文章能夠幫到大家解決工作中監(jiān)控死鎖的問題。
【編輯推薦】
