昨天在系统升级前，另外一套系统出现了一个紧急任务，赶过去救火，他们反馈说有一个job处理很慢，已经很长的时间了还是没有任何反应。想让我看看是什么地方出问题了。
我检查了系统的负载，数据库的top process,都没有发现什么问题。我都有点纳闷他们的job到底跑了没，系统的空间资源很多，反应却很慢。
查看锁的情况时，只有一条记录，这条记录引起了我的注意。
Current Locks
-------------
SID_SERIAL ORACLE_USE OBJECT_NAME LOGON_TIM SEC_WAIT OSUSER MACHINE PROGRAM STATE STATUS LOCK_ MODE_HELD
------------ ---------- --------------- --------- -------- ---------- ---------- -------------------- ---------- ---------- ----- ----------
191,5379 XXXXXX AUDIT_BALANCE 07-OCT-14 2 cpt01 machine02 PRManager@testwl(TNS V1-V3) WAITING INACTIVE DML Row-X (SX)
猛一看这条记录没有什么问题，等待的时间也很短。
我的印象中这个表是使用db link创建同义词的方式访问的。
和他们确认了下，这个job会涉及5个库，我们就叫做sourcedb1,userdb1,userdb2,userdb3,userdb4
其中真正的表是在sourcedb1里面，然后在userdb1,userdb2,userdb3,userdb4里面创建了db link，然后通过同义词的方式来访问。
刚才查看的是sourcedb1,我又查看了一下其他的几个库，负载都很低，但是一个共同点就是都有这么一个锁。
Current Locks
-------------
SID_SERIAL ORACLE_USE OBJECT_NAME LOGON_TIM SEC_WAIT OSUSER MACHINE PROGRAM STATE STATUS LOCK_ MODE_HELD
------------ ---------- --------------- --------- -------- ---------- ---------- -------------------- ---------- ---------- ----- ----------
380,11 XXXXXX2 AUDIT_BALANCE 07-OCT-14 2 cpt01 machine02 PRManager@testwl(TNS V1-V3) WAITING INACTIVE DML Row-X (SX)
唯一的不同之处就在于session不同。
这个问题就是由于db link锁导致的，在和开发确认后，可以清理这个session，他们重新跑一个这个Job.
我本以为在sourcedb1里面清理了锁之后，其余的库的lock也就会自动清除，但是清理了之后sourcedb1的lock之后，userdb1,userdb2,userdb3,userdb4的lock还在那儿。
最后还是一个一个单独做的清理。但是问题处理的紧急，其他的也就没有再做总结。
最后想来还是做一个简单的实验来说明一下db link的这个问题。
我们需要使用两个库，通过db link的方式来修改数据，看看锁的情况。
我创建了一个表，然后在另外一个库中创建了db link，然后创建了同义词来访问。
> sqlplus n1/n1@db1
SQL> create table test_link as select *from cat; --创建了基表
Table created.
SQL> conn n1/n1@db2
Connected.
SQL> create database link link_db1 connect to n1 identified by n1 using 'db1'; --创建了db link
Database link created.
SQL> create synonym test_link for test_link@link_db1; --创建了同义词
Synonym created.
SQL> update test_link set table_name='a' ; --这个时候通过db link来修改数据。
20 rows updated.
SQL> select sid from v$mystat where rownum SID
----------
179
SQL> select sid,serial# from v$session where sid=179; --通过db link访问的库session
SID SERIAL#
---------- ----------
179 959
这个时候查看锁的情况，发现在源库上出现了一个锁，对应着一个session做dml操作。
SID SER# STA User Os user Os Proc Locked Object
------ ------ --- --------------- ---------- -------------------- -------------------------
269 24847 INA N1 oracle 9021 TEST_LINK
可以看到在源库上有一个lock，还存在着一个对应的session来做映射。
所以个人建议还是在使用db link的时候有所保留。用起来方便但是还是有一些潜在的隐患。