1:查V$DB_OBJECT_CACHEsql
SELECT * FROM V$DB_OBJECT_CACHE WHERE name='CUX_OE_ORDER_RPT_PKG' AND LOCKS!='0';数据库
注意:CUX_OE_ORDER_RPT_PKG 为存储过程的名称。session
发现 locks=2oracle
2:按对象查出sid的值spa
select /*+ rule*/ SID from V$ACCESS WHERE object='CUX_OE_ORDER_RPT_PKG';.net
注意:CUX_OE_ORDER_RPT_PKG 为存储过程的名称。对象
3:查sid,serial#blog
SELECT SID,SERIAL#,PADDR FROM V$SESSION WHERE SID='刚才查到的SID';事件
四、根据会话id(sid),此会话的等待事件:ip
event字段即为等待事件。查询后咱们发现这个会话等待事件为SQL*Net message from dblink;在查看会话的logon_time为两天前。这个时间远超过咱们估计时间。
五、根据会话id查看此会话正在执行的sql语句
查询后发现正在执行的sql语句为经过dblink到远程数据库上A表查询数据,插入到B表。
六、链接远程数据库,查询当前被锁的对象
查看后发现远程数据库中并无涉及到A、B表被锁
七、查看远程数据的会话:
使用dblink链接远程数据库,在远程数据库上的会话的program应该是是oracle.exe
查询后发现,两个远程库有时候根本没有相关会话,有时候可能有相关会话,但其等待事件是 SQL*Net message from client 远程库在等待本地Oracle给他发请求。
本地库等dblink远程库,远程库等待client消息。看来这个存储过程是不可能执行完了。
具体什么缘由形成了,还不清楚。
这里给出的处理方法就是杀死会话
http://blog.csdn.net/fupei/article/details/7325190
具体步骤可参考上面的文章