DB2 V9.7 锁事件监控

核心提示： 清单 16. 应用 1 修改 stock 表数据db2+c"updatedb2admin.stocksetqty=qty+1whereitemno=259"清单 17. 应用 2 修改 stock 表数据db2+c"updatedb2admin.stocksetqt

清单 16. 应用 1 修改 stock 表数据

　db2　+c　"update　db2admin.stock　set　qty=qty+1　where　itemno=259"　

清单 17. 应用 2 修改 stock 表数据

　db2　+c　"update　db2admin.stock　set　qty=qty+1　where　itemno=259"　
　DB21034E　该命令被当作　SQL　语句来处理，因为它是无效的“命令行处理器”命令。　
在　SQL　处理期间，它返回：SQL0911N　因为死锁或超时，所以当前事务已回滚。　
原因码为　"68"。　SQLSTATE=40001　

在经过 30 秒钟的等待后，应用 2 返回 SQL0911N 错，原因码为 68 表示发生了锁超时。我们使用下面程序格式化事件数据。

清单 18. 格式化锁超时事件数据

　db2　set　event　monitor　locktimeout　state　0　
　
　db2　"call　EVMON_FORMAT_UE_TO_TABLES　
　(　'LOCKING',　NULL,　NULL,　NULL,　NULL,　NULL,　'RECREATE_FORCE',　-1,　
'SELECT　*　FROM　locktimeout　ORDER　BY　event_timestamp')"　

我们查询 LOCK_EVENT 发现存在两个事件，一个事件为 LOCKWAIT 一个事件为 LOCKTIMEOUT。这表明在锁超时事件发生之前，由于等待时间超过了 5 秒（参数 MON_LW_THRESH 设置的值），先发生了锁等待事件，然后才发生锁超时。查询表 LOCK_PARTICIPANTS 显示相关锁事件的参与方，查询表 LOCK_PARTICIPANT_ACTIVITIES 显示参与者执行 SQL 的历史。

清单 19. 锁超时事件

　db2　"select　substr(XMLID,1,64)　xml_id　from　LOCK_EVENT"　
　
　XML_ID　
　----------------------------------------------------------------　
　db2LockEvent_2_LOCKWAIT_2009-11-18-17.34.09.292636_0　
　db2LockEvent_3_LOCKTIMEOUT_2009-11-18-17.34.34.292606_0　
　
　
　db2　"select　PARTICIPANT_NO　as　p_no,　PARTICIPANT_TYPE　as　p_type,　
　PARTICIPANT_NO_HOLDING_LK　as　p_no_holdling_lk,　APPLICATION_HANDLE　as　
　appl_hanle,substr(TABLE_NAME,1,10)　as　t_name　from　LOCK_PARTICIPANTS"　
　
　P_NO　P_TYPE　P_NO_HOLDLING_LK　APPL_HANLE　T_name　
　1　Requester　2　14　STOCK　
　2　Owner　-　7　-