赞
踩
我们的系统采用了Oracle 10G数据库。在运行过程中,经常发生一些存储过程执行时间很长,比如几天,远超过我们的预期。这时候就要查看一下,当前执行此存储过程的回话等待事件是什么,再进一步决定如何处理。
1、首先确定执行此存储过程的会话,o.kglnaobj即为会话锁住的存储过程名称:
- Select distinct s.sid ,s.SERIAL#, username ,o.kglnaobj
- from v$session s , sys.x$kglob o , sys.x$kglpn p where p.kglpnhdl=o.kglhdadr and s.saddr=p.kglpnuse ;
2、根据会话id(sid),此会话的等待事件:
select * from v$session where sid=***;
event字段即为等待事件。查询后我们发现这个会话等待事件为SQL*Net message from dblink;在查看会话的logon_time为两天前。这个时间远超过我们估计时间。
3、根据会话id查看此会话正在执行的sql语句
select sql_text from v$sqlarea where address= (select sql_address from v$session where sid=***);
查询后发现正在执行的sql语句为通过dblink到远程数据库上A表查询数据,插入到B表。
4、连接远程数据库,查询当前被锁的对象
- select * from v$locked_object lo ,
- all_objects ao where lo.OBJECT_ID= ao.object_id ;
查看后发现远程数据库中并没有涉及到A、B表被锁
5、查看远程数据的会话:
select * from v$session where terminal like '%机器名%' and program='Oracle.exe'
使用dblink连接远程数据库,在远程数据库上的会话的program应该是是oracle.exe
查询后发现,两个远程库有时候根本没有相关会话,有时候可能有相关会话,但其等待事件是 SQL*Net message from client 远程库在等待本地Oracle给他发请求。
本地库等dblink远程库,远程库等待client消息。看来这个存储过程是不可能执行完了。
具体什么原因造成了,还不清楚。
这里给出的处理方法就是杀死会话
http://blog.csdn.net/fupei/article/details/7325190
具体步骤可参考上面的文章
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。