环境:LINUX
db2level:
DB21085I Instance "db2inst1" uses "64" bits and DB2 code release "SQL09010" with level identifier "02010107".
Informational tokens are "DB2 v9.1.0.0", "s060629", "LINUXAMD64", and Fix Pack "0".
问题:
数据库不会检测死锁和锁超时。
也就是说理论上应该检测到死锁和锁超时的并发上面,这个数据库没有检测出来,然后一直在锁等待。
db2 get db cfg for TSO | grep -i LOCK
Max storage for lock list (4KB) (LOCKLIST) = AUTOMATIC
Percent. of lock lists per application (MAXLOCKS) = AUTOMATIC
Interval for checking deadlock (ms) (DLCHKTIME) = 10000
Lock timeout (sec) (LOCKTIMEOUT) = 15
Block log on disk full (BLK_LOG_DSK_FUL) = NO
DB2DETAILDEADLOCK的state确认为1。
请问,DB2的死锁和锁超时检测,在什么情况下会失效,该如何检查?万望赐教。
这个数据库不是我部署的,我也对部署这个库的人很无力。
检查下数据库管理器(dbm)中监控开关的设置情况,db2 get monitor switches | grep -i lock
每个连接至数据库的应用程序(会话)都有其自己的监视器开关集,这些监视器开关与数据库管理器和其他应用程序无关。应用程序在连接至数据库时,从数据库管理器上继承他们的监视器开关设置。可以执行:get monitor switches 命令查看所有的监视开关设置情况。
你把 LOCKTIMEOUT 修改成 15 以后有没有重启?
the database must be shutdown and reactivated before the configuration parameter changes
become effective.
如果没生效将是下面的结果
db2 get db cfg |grep LOCKTIMEOUT
Lock timeout (sec) (LOCKTIMEOUT) = 15
$ db2 get db cfg show detail |grep LOCKTIMEOUT
Lock timeout (sec) (LOCKTIMEOUT) = -1 15
我的死锁测试例子是这样的:
假设表TAB里面有4条记录,分别表示为r1,r2,r3,r4
我是自己开了2个会话窗口:
会话1 update r1 不提交
会话2 update r2 不提交
会话1 select r2 进入锁等待。。。
会话2 select r1 也进入锁等待。。。
之后就是无限的锁等待
正常情况下,最后一步是会出现死锁回滚的。
我在另外一个环境上面测试,是会正常死锁回滚的,就这个环境不会。
Default database monitor switches
Buffer pool (DFT_MON_BUFPOOL) = ON
Lock (DFT_MON_LOCK) = ON
Sort (DFT_MON_SORT) = ON
Statement (DFT_MON_STMT) = ON
Table (DFT_MON_TABLE) = ON
Timestamp (DFT_MON_TIMESTAMP) = ON
Unit of work (DFT_MON_UOW) = ON
Monitor health of instance and databases (HEALTH_MON) = ON
快照监控已经全开。
分割线*
问题解决了,升级DB2 补丁就OK了。