业务人员测试了一个存储过程(用test.sh启动sqlplus调用sql脚本方式)
之后在操作系统层 kill -9 XXX 把它杀了
但是发现测试用的表TAB_TEST数据一直在增加(此存储过程插入该表)
ps -ef|grep test.sh --不存在
ps -ef|grep sqlplus --不存在
怪事?!
于是从DB入手:
查看目前在运行的存储过程
select *
from v$db_object_cache
where locks > 0 and pins > 0 and type='PROCEDURE';
from v$db_object_cache
where locks > 0 and pins > 0 and type='PROCEDURE';
发现该存储过程果然还在!
考虑到是insert操作,调用如下语句以期查找到对应的sid
select spid,s.sid,s.serial#,s.username,s.program,s.machine,p.program,s.status,sql_text from v$session s,v$process p,v$sql s1
where s.sql_hash_value=s1.HASH_VALUE
and p.addr=s.paddr
and sql_text like 'insert%';
where s.sql_hash_value=s1.HASH_VALUE
and p.addr=s.paddr
and sql_text like 'insert%';
居然没有记录!
考虑到是insert操作肯定有锁的存在,于是运行如下语句查找相关锁的sid!
select spid,s.sid,s.serial#,s.username,s.program,s.machine,p.program,s.status,sql_text from v$session s,v$process p,v$sql s1
where s.sql_hash_value=s1.HASH_VALUE
and p.addr=s.paddr
and s.sid in(select session_id from v$locked_object);
where s.sql_hash_value=s1.HASH_VALUE
and p.addr=s.paddr
and s.sid in(select session_id from v$locked_object);
发现有一个session在‘truncate table XXX’比较可疑,反复执行上面的语句,这个sid终于出现了'insert into
TAB_TEST'的操作。
对比存储过程源码,匹配!
alter system kill session '123,1234';
由于先入为主的原因,一开始就走了弯路。以为是有表数据的增加就一定在执行insert操作。
其实未必。。。。。
下班,走人!
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10937311/viewspace-267630/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10937311/viewspace-267630/