分化监控后果
本节我们入手下手具体分化上一节孕育发生的监控后果，从监控导出的日记文件中，我们可以分化出死锁孕育发生的时分，级别，体式格局以及孕育发生死锁的SQL语句，从而据此来进一阵势修正大约由挨次并发筹算大约数据库筹算所招致的缺陷。
---------------------------------
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表上孕育发生的事务）
我们可以分化一下dllog1.txt 文件，来正确定位死锁孕育发生的缘由，看看5）Deadlocked Connection: 我们可以看出死锁孕育发生的表是EMPLOYEE，同时我们也可以鉴定出这是一个凑合已被排他锁占有的资本央求共享锁所招致的死锁。加倍紧张的是我们失掉了孕育发生死锁的SQL语句，从下面我们可以推想出一定存在其他行使挨次在以独占锁的体式格局占用EMPLOYEE表，这很有大约即是凑合EMPLOYEE表的拔出大约更新步履形成的。
而这最有大约即是拔出大约更新事务时分过长所招致的，招致事务时分过长的缘由大大要有两种，一是来自于并发挨次的筹算和编写，二是来自于数据库的筹算和数据库参数的调停。
本节我们议决仔细地分化事务监控器的后果来推想出招致死锁孕育发生的缘由，从而采用无效的方法去克制死锁的孕育发生。这些方法搜罗调停数据库参数，大约改削行使挨次的代码，大约改削SQL语句以致是数据库的筹算来提高代码和SQL语句实验的驯服。
克制死锁的方法
越早地思索数据库筹算中的并发性标题成绩，就越可以提高代码实验的驯服，降低挨次开发和维护的成本，这里我们提出了一些克制死锁，提高行使挨次并发性的方法。
设置隔离级别，根据行使挨次的营业逻辑和数据无缺性需求来决议吻合的隔离级别，搜罗：RR，RS，CS，UR。该决议需求对行使挨次需求和关连的营业规则例矩具有根底晓畅
尽量克制锁升级，正确调停参数LOCKLIST, MAXLOCKS
SQL0911N前往码68（LOCKTIMEOUT参数）的缘由是锁期待超时，而SQL0911前往码2（DLCHKTIME参数）的缘由则是因为死锁被逼迫回滚，克制这两种错误的方法即是公道筹算数据库和竖立公道的索引
尽快提交事务，不要在事务中插足不用要的实验时分过长的代码，歧大大的代码循环和远程调用，大约一些没无效处的SELECT语句
行使挨次的框架完成担保一旦创造SQL错误，连忙实验回滚事务，释放锁。
假设多个行使挨次拜候统一资本，最好以沟通的次序拜候。这样，即便前一个拜候资本的行使挨次会延迟其他行使挨次的拜候，也不会招致死锁的孕育发生
设定外键索引，假想象删除父表中的行，就需求扫描多个子表中的多行数据，这样就需求占用多个子表的锁，我们可以议决在外键上竖立索引来裁汰扫描子表的行数，否则若不竖立索引，假设从父表中删除一行的时分，就需求扫描整个子表。
总结
在我门完成这个例子的实际过程中，大大家可以看到差别DB2东西（DBC CLI, SQL, DB2EVMON）的运用实例，而且可以学会如何渐渐地操纵死锁事务监控器来监控死锁的孕育发生，最初我门把握的内容是如何分化那些从死锁监控器得来的后果，以及采用呼应的方法来克制死锁的孕育发生。
来自: 新客网(www.xker.com) 详文参考：http://www.xker.com/page/e2008/0128/46637_3.html
版权声明：
原创作品，允许转载，转载时请务必以超链接体式格局标明文章 原始来由 、作者信息和本声明。否则将追查司法责任。