锁表原因查询

下午测试人员报告PrpLRForecast表不能for upadate了，问是不是这张表被锁了。

通过以下SQL查询果然发现此表被锁。

SELECT /*+ rule */ s.username, decode(l.type, 'TM', 'TABLE LOCK', 'TX', 'ROW LOCK', NULL) LOCK_LEVEL, o.owner, o.object_name, o.object_type, s.sid, s.serial#, s.terminal, s.machine, s.program, s.osuser FROM gv$session s, gv$lock l, dba_objects o WHERE l.sid = s.sid AND l.id1 = o.object_id(+) AND s.username is NOT NULL ; USERNAME LOCK_LEVEL OWNER OBJECT_NAME OBJECT_TYPE SID SERIAL# TERMINAL MACHINE 7601 TABLE LOCK 7601 PRPLRFORECAST TABLE 336 19493 CAIC16 CAIC16

 
发现PrpLRForecast表果然被锁。从MACHINE结果看所表的sql是从应用服务器CAIC16上发出的。

查看SID=336的session在等待什么。

SQL> select sid,seq# ,event from v$session_wait t where t.sid='386'; SID SEQ# EVENT ---------- ---------- ---------------------------------------------- 386 130 SQL*Net message from client

从等待事件EVENT的结果SQL*Net message from client来看，简单判断为是网络问题。就根据sid，seq# 把这个session给kill掉了。再次运行锁表的sql，没发有表被锁。问题貌似解决。

    第二天早上，测试人员让帮忙查看是否相同的表是否又被锁了。运行锁表的sql一看，果然是被锁了。同样是昨天那个应用的机器发出的sql，再次查看等待事件，也跟昨天一样。怀疑是开发人员的代码有问题，找到开发人员跟踪程序后果然发现有个连接池只open了，但没有关闭。原来开发这段代码的人打开这个连接池后只是做了查询，没有关闭也就没有锁表的问题。但现在他增加了一些功能有update的操作，没有仔细读原来的代码。也没有关连接池。所以出现了锁表的情况。

 

    项目组有规定连接池打开后一定要关闭，也有类似的代码检查工具。但时间长了就有些大意了，并不是每次提交测试的代码都经过代码走查工具检查后再提交的。

   

     总结此次锁表的诊断结过程，发现自己的思维还不是很严谨。有时候会想当然的去解决一些事情。幸好是在测试环境发现的问题，要是在生产出现类似问题可就严重了。