enq: DX - contention 是分布式事务所使用的锁。

select * from v$lock where type='DX'

发现

C0000001380D5D00 C0000001380D5D20 2833 DX 16 0 1 0 1121192 0
C0000001380E76C8 C0000001380E76E8 2234 DX 51 0 4 0 4150509 1
C0000001380E7B08 C0000001380E7B28 2784 DX 51 0 0 6 4150445 0

这些锁的时间可不小啊，原来是2234堵住了2784，而且时间很久了，杀掉2234后，正常

不过 DX 这个锁是如何发生的呢，做了一个小测试

数据库A，数据库B

数据库A上有 dblinkB 连接到数据库B

用plsql执行

Select * from tableB@dblinkb

当数据没有全部显示出来的时候，会发现

数据库A上：

1) 产生了一个事务，需要commit 或者 rollback

2) 查询v$lock 发现，当前session 有2个锁

C0000000FE540D28 C0000000FE540D48 1068 DX 38 0 4 0 0 0

C0000000FC4AC0F8 C0000000FC4AC130 1068 TX 589828 22700 6 0 51 0

数据库B上：

1） session 表中的 TADDR 字段有值，是个事务，不过在v$transaction中查找不到，不过可以在x$ktcxb 中找到

执行 create table action_test1 as select * from tableB@dblink

数据库A上：

1) v$lock上该进程的锁有

C0000000FE540D28 C0000000FE540D48 1069 DX 8 0 1 0 0 0

C0000000FCB9FDA8 C0000000FCB9FDE0 1069 TX 196641 20879 6 0 5 0

C0000000FC8356F8 C0000000FC835720 1069 TM 113886 0 3 0 5 0

还发现出现过：

C0000000FE540EF0 C0000000FE540F10 1069 FB 5 21422737 6 0 0 0

数据库B上：

1） V$lock 中出现：

C0000001380D6860 C0000001380D6880 2897 DX 29 0 4 0 0 0

总结：

使用dblink的时候在本地和远程数据库上都会出现DX锁，是分部式事务用到的，ID1的含义暂时不明,DX锁的一般都是系统表，到底是锁的什么资源，也不知道

问题应该就是远程数据库通过dblink取数据，结果网络出问题导致事务一直没有结束，DX没有释放，第2次执行的时候就一直等待DX资源，奇怪的是第2次执行的时候应该申请其他DX资源，为什么会申请上次出错的资源呢？