【完結篇】 遇到的詭異問題，終於解決了，原來是因為鎖

     折磨我一天的問題，今天又進行了進一步分析，發現可能出現了不斷引用自己的死迴圈。、

     注意，這裡面是無窮盡的，在往後你可以繼續點。我開始回憶這次測試的整個過程：
     我一開始建立同義詞的時候，db_LINK建立錯了，指的庫是自己的庫，我們再來捋一遍，我要建立同義詞所指的表名是bsvc, 而我的同義詞也叫bsvc,新庫裡建立的空表也叫bsvc，全是一樣的，我想，是不是我建同義詞的時候，由於是私有同義詞，所以提前把原表先改名，建之後，DB_LINK指到了自己的庫裡，但是庫裡還沒有這個表，只有一個同義詞，然後就引用同義詞，同義詞再引用，導致了死迴圈，永遠的沒有盡頭。

     但是這種死迴圈的情況，在網上搜了一大圈，依然沒有解決的方法，最後聽從一朋友的建議，還是從鎖的角度出發，解決這個問題。

透過這條SQL語句：
SELECT /*+ rule */ s.username,
 decode(l.type,'TM','TABLE LOCK',
 'TX','ROW LOCK',
 NULL) LOCK_LEVEL,
 o.owner,o.object_name,o.object_type,
 s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser,s.LOGON_TIME
 FROM v$session s,v$lock l,dba_objects o
 WHERE l.sid = s.sid
 AND l.id1 = o.object_id(+)
 AND s.username is NOT Null

查出昨天有很多鎖沒有釋放。其實我昨天也看了很多，但沒有鎖所涉及的表跟BSVC有關，所以沒有在意，昨天的鎖還沒有解決，而且今天也沒有什麼鎖發生，所以我決定把這些鎖全部KILL

運用alter system kill session ()   語句  殺掉之後，在v$session裡檢視他們的狀態，變成了killed ，資源還沒有全部釋放，所以我們只能從作業系統層面殺掉程式了。


當一個session被kill掉以後，該session的paddr被修改，如果有多個session被kill，那麼多個session
的paddr都被更改為相同的程式地址。那我們怎麼獲得真正的paddr呢？運用下面的語句

SQL> select p.addr from v$process p where pid <> 1
  2     minus
  3      select s.paddr from v$session s;
select spid from v$process where ADDR in ( select p.addr from v$process p where pid <> 1   minus   select s.paddr from v$session s)
SQL> select spid from v$process where ADDR in ( select p.addr from v$process p where pid <> 1   minus   select s.paddr from v$session s)
spid算出來了，在作業系統上kill -9 全部殺掉之後，同義詞終於可以刪除了。問題解決