下午内网测试库同事反应查询更新数据很慢，有时甚至表都打不开，后来通过服务器【linux】的top命令查看了下，cpu和mem占用正常，但wait高达80%多(下面两图显示的就是问题前后观察EM对比的截图,版本是oracle10gR2，EM的效果比oracle11gR2逊色不少哈)：
-------------------------------------->>
---------------------------->>
接着通过sqldevelpdev客户端查询有没有锁等待之类会话事件，果然有，而且是两个session持有TX锁，然后通过下面的sql查询从oracle和linux级别kill掉了相应session,以为风波就此平静，结果过了不到一分钟查询又出现，只不过这次只有一个session持有TX锁，于是就去查找对应的sql_txt,找到后发现是个同事写的存储过程，定时任务，当时正在运行，让其确认下是不是任务执行出问题了，结果一查，是程序问题，造成的死循环，它会批量发起会话，kill一个后接着又锁，循环反复，后来他改了下程序后重新运行，一切恢复通畅.
|
--查询死锁 select sess.sid, sess.serial#, lo.oracle_username, lo.os_user_name, ao.object_name, lo.locked_mode from v$locked_object lo, dba_objects ao,v$session sess where ao.object_id = lo.object_id and lo.session_id = sess.sid; --oracle级别kill session alter system kill session '1627,1'; alter system kill session '1564,64740'; --查询当前连接会话 select s.value,s.sid,a.username,a.MACHINE from v$sesstat S,v$statname N,v$session A where n.statistic#=s.statistic# and name='session pga memory' and s.sid=a.sid and a.sid=1626 order by s.value; --查询造成死锁的sql语句 SELECT a.SID, a.username, s.sql_text FROM v$session a, v$sqltext s WHERE a.sql_address = s.address AND a.sql_hash_value = s.hash_value and a.SID=1626 ORDER BY a.username, a.SID, s.piece; --造成锁等待的操作内容 begin flt_com.p_line_relation_change(:A0,:B0,:C0,:D0,:E0,:ret_errorcode,:ret_errorname); end; --通过sid查找pid，进而通过系统级别kill select spid, osuser, s.program from v$session s,v$process p where s.paddr=p.addr and s.sid=1605; --服务器级别kill kill -9 spid --------------------------------over game |
最新内容请见作者的GitHub页：http://qaseven.github.io/