1：查V$DB_OBJECT_CACHE

SELECT * FROM V$DB_OBJECT_CACHE WHERE name='CUX_OE_ORDER_RPT_PKG' AND LOCKS!='0';

注意：CUX_OE_ORDER_RPT_PKG 為儲存過程的名稱。

發現 locks＝2

2：按物件查出sid的值

select /*+ rule*/  SID from V$ACCESS WHERE object='CUX_OE_ORDER_RPT_PKG';

注意：CUX_OE_ORDER_RPT_PKG 為儲存過程的名稱。

3：查sid,serial#

SELECT SID,SERIAL#,PADDR FROM V$SESSION WHERE SID='剛才查到的SID';

4、根據會話id（sid），此會話的等待事件：

1. select * from v$session where sid=***;  

event欄位即為等待事件。查詢後我們發現這個會話等待事件為SQL*Net message from dblink；在檢視會話的logon_time為兩天前。這個時間遠超過我們估計時間。

5、根據會話id檢視此會話正在執行的sql語句

1. select sql_text from v$sqlarea where address= (select   sql_address  from v$session where sid=***);  

查詢後發現正在執行的sql語句為通過dblink到遠端資料庫上A表查詢資料，插入到B表。

6、連線遠端資料庫，查詢當前被鎖的物件

1. select * from v$locked_object lo ,   
2. all_objects  ao    where lo.OBJECT_ID= ao.object_id ;  

檢視後發現遠端資料庫中並沒有涉及到A、B表被鎖

7、檢視遠端資料的會話：

1. select * from v$session where terminal like '%機器名%'  and program='Oracle.exe'  

使用dblink連線遠端資料庫，在遠端資料庫上的會話的program應該是是oracle.exe

查詢後發現，兩個遠端庫有時候根本沒有相關會話，有時候可能有相關會話，但其等待事件是 SQL*Net message from client 遠端庫在等待本地Oracle給他發請求。

本地庫等dblink遠端庫，遠端庫等待client訊息。看來這個儲存過程是不可能執行完了。

具體什麼原因造成了，還不清楚。