DB2和 Oracle的并发控制（锁）的比较（3）

4.2 事件监控方式：

当使用事件监控器进行锁的监控时候，只能监控死锁(死锁的产生是因为由于锁请求冲突而不能结束事务，并且该请求冲突不能够在本事务内解决。通常是两个应用程序互相持有对方所需要的锁，在得不到自己所需要的锁的情况下，也不会释放现有的锁)的情况，具体步骤如下：
db2 create event monitor dlock for deadlocks with details write to file '$HOME/dir'
db2 set event monitor dlock state 1
db2evmon -db dbname -evm dlock看具体的死锁输出（如下图）

Deadlocked Connection ...
Deadlock ID: 4
Participant no.: 1
Participant no. holding the lock: 2
Appl Id: G9B58B1E.D4EA.08D387230817
Appl Seq number: 0336
Appl Id of connection holding the lock: G9B58B1E.D573.079237231003
Seq. no. of connection holding the lock: 0126
Lock wait start time: 06/08/2005 08:10:34.219490
Lock Name : 0x000201350000030E0000000052
Lock Attributes : 0x00000000
Release Flags : 0x40000000
Lock Count : 1
Hold Count : 0
Current Mode : NS - Share (and Next Key Share)
Deadlock detection time: 06/08/2005 08:10:39.828792
Table of lock waited on : ORDERS
Schema of lock waited on : DB2INST1
Tablespace of lock waited on : USERSPACE1
Type of lock: Row
Mode of lock: NS - Share (and Next Key Share)
Mode application requested on lock: X - Exclusive
Node lock occured on: 0
Lock object name: 782
Application Handle: 298
Deadlocked Statement:
Type : Dynamic
Operation: Execute
Section : 34
Creator : NULLID
Package : SYSSN300
Cursor : SQL_CURSN300C34
Cursor was blocking: FALSE
Text : UPDATE ORDERS SET TOTALTAX = ?, TOTALSHIPPING = ?,
LOCKED = ?, TOTALTAXSHIPPING = ?, STATUS = ?, FIELD2 = ?, TIMEPLACED = ?,
FIELD3 = ?, CURRENCY = ?, SEQUENCE = ?, TOTALADJUSTMENT = ?, ORMORDER = ?,
SHIPASCOMPLETE = ?, PROVIDERORDERNUM = ?, TOTALPRODUCT = ?, DESCRIPTION = ?,
MEMBER_ID = ?, ORGENTITY_ID = ?, FIELD1 = ?, STOREENT_ID = ?, ORDCHNLTYP_ID = ?,
ADDRESS_ID = ?, LASTUPDATE = ?, COMMENTS = ?, NOTIFICATIONID = ? WHERE ORDERS_ID = ?
List of Locks:
Lock Name : 0x000201350000030E0000000052
Lock Attributes : 0x00000000
Release Flags : 0x40000000
Lock Count : 2
Hold Count : 0
Lock Object Name : 782
Object Type : Row
Tablespace Name : USERSPACE1
Table Schema : DB2INST1
Table Name : ORDERS
Mode : X - Exclusive
Lock Name : 0x00020040000029B30000000052
Lock Attributes : 0x00000020
Release Flags : 0x40000000
Lock Count : 1
Hold Count : 0
Lock Object Name : 10675
Object Type : Row
Tablespace Name : USERSPACE1
Table Schema : DB2INST1
Table Name : BKORDITEM
Mode : X - Exclusive（略去后面信息）
5 Oracle 多粒度封锁机制的监控
为了监控Oracle系统中锁的状况，我们需要对几个系统视图有所了解：
5.1 v$lock视图
v$lock视图列出当前系统持有的或正在申请的所有锁的情况，其主要字段说明如下：
表七：v$lock视图主要字段说明
其中在TYPE字段的取值中，本文只关心TM、TX两种DML锁类型；
5.2 v$locked_object视图
v$locked_object视图列出当前系统中哪些对象正被锁定，其主要字段说明如下：
表八：v$locked_object视图字段说明
5.3 Oracle锁监控脚本
根据上述系统视图，可以编制脚本来监控数据库中锁的状况。
5.3.1 showlock.sql
第一个脚本showlock.sql，该脚本通过连接v$locked_object与all_objects两视图，显示哪些对象被哪些会话锁住：

/* showlock.sql */
column o_name format a10
column lock_type format a20
column object_name format a15
select rpad(oracle_username,10) o_name,session_id sid,
decode(locked_mode,0,'None',1,'Null',2,'Row share',
3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive') lock_type,
object_name ,xidusn,xidslot,xidsqn
from v$locked_object,all_objects
where v$locked_object.object_id=all_objects.object_id;
5.3.2 showalllock.sql
第二个脚本showalllock.sql，该脚本主要显示当前所有TM、TX锁的信息；

/* showalllock.sql */
select sid,type,id1,id2,
decode(lmode,0,'None',1,'Null',2,'Row share',
3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive')
lock_type,request,ctime,block
from v$lock
where TYPE IN('TX','TM');
6 DB2 多粒度封锁机制示例
以下示例均运行在DB2 UDB中，适用所有数据库版本。首先打开三个命令行窗口(DB2 CLP)，其中两个（以下用SESS#1、SESS#2表示）以db2admin用户连入数据库，以操作SAMPLE库中提供的示例表（employee）；另一个（以下用SESS#3表示）以db2admin用户连入数据库，对执行的每一种类型的SQL语句监控加锁的情况；希望读者通过这种方式对每一种类型的SQL语句监控加锁的情况。(因为示例篇幅很大，笔者在此就不做了，建议读者用类似方法验证加锁情况)

/home/db2inst1>db2 +c update employee set comm=9999(SESS#1)
/home/db2inst1>db2 +c select * from employee(SESS#2处于lock wait)
/home/db2inst1>db2 +c get snapshot for locks on sample(SESS#3监控加锁情况)
注：db2 +c为不自动提交（commit）SQL语句，也可以通过 db2 update command options using c off关闭自动提交（autocommit，缺省是自动提交）
7 总结
总的来说，DB2的锁和Oracle的锁主要有以下大的区别：
1．Oracle通过具有意向锁的多粒度封锁机制进行并发控制，保证数据的一致性。其DML锁（数据锁）分为两个层次（粒度）：即表级和行级。通常的DML操作在表级获得的只是意向锁（RS或RX），其真正的封锁粒度还是在行级；DB2也是通过具有意向锁的多粒度封锁机制进行并发控制，保证数据的一致性。其DML锁（数据锁）分为两个层次（粒度）：即表级和行级。通常的DML操作在表级获得的只是意向锁（IS，SIX或IX），其真正的封锁粒度也是在行级；另外，在Oracle数据库中，单纯地读数据（SELECT）并不加锁，这些都提高了系统的并发程度，Oracle强调的是能够"读"到数据，并且能够快速的进行数据读取。而DB2的锁强调的是"读一致性"，进行读数据(SELECT)时会根据不同的隔离级别（RR,RS,CS）而分别加S,IS,IS锁，只有在使用UR隔离级别时才不加锁。从而保证不同应用程序和用户读取的数据是一致的。
2. 在支持高并发度的同时，DB2和Oracle对锁的操纵机制有所不同：Oracle利用意向锁及数据行上加锁标志位等设计技巧，减小了Oracle维护行级锁的开销，使其在数据库并发控制方面有着一定的优势。而DB2中对每个锁会在锁的内存（locklist）中申请分配一定字节的内存空间，具体是X锁64字节内存，S锁32字节内存（注：DB2 V8之前是X锁72字节内存而S锁36字节内存）。
3. Oracle数据库中不存在锁升级，而DB2数据库中当数据库表中行级锁的使用超过locklist*maxlocks会发生锁升级。
4. 在Oracle中当一个session对表进行insert，update，delete时候，另外一个session仍然可以从Orace回滚段或者还原表空间中读取该表的前映象（before image）; 而在DB2中当一个session对表进行insert，update，delete时候，另外一个session仍然在读取该表数据时候会处于lock wait状态，除非使用UR隔离级别可以读取第一个session的未提交的值；所以Oracle同一时刻不同的session有读不一致的现象，而DB2在同一时刻所有的session都是"读一致"的。
8 结束语
DB2中关于并发控制（锁）的建议
1．正确调整locklist，maxlocks，dlchktime和locktimeout等和锁有关的数据库配置参数（locktimeout最好不要等于-1）。如果锁内存不足会报SQL0912错误而影响并发。
2．写出高效而简洁的SQL语句（非常重要）。
3．在业务逻辑处理完后尽可能快速commit释放锁。
4．对引起锁等待（SQL0911返回码68）和死锁（SQL0911返回码2）的SQL语句创建最合理的索引（非常重要，尽量创建复合索引和包含索引）。
5．使用 altER TABLE 语句的 LOCKSIZE 参数控制如何在持久基础上对某个特定表进行锁定。检查syscat.tables中locksize字段，尽量在符合业务逻辑的情况下，每个表中该字段为"R"（行级锁）。
6．根据业务逻辑使用正确的隔离级别（RR，RS，CS和UR）。
7．当执行大量更新时，更新之前，在整个事务期间锁定整个表（使用 SQL LOCK TABLE 语句）。这只使用了一把锁从而防止其它事务进行这些更新，但是对于其他用户它的确减少了数据并发性。