注意，这里面是无穷尽的，在往后你可以继续点。我开始回忆这次测试的整个过程：
我一开始建立同义词的时候，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 全部杀掉之后，同义词终于可以删除了。问题解决