跨库的DB_LINK导致的数据库锁故障的处理

2pc涉及到2个阶段，3个操作
阶段一：“准备提交”，事务协调者向所有操作者发起prepare，所有参与者回答yes/no。
阶段二：“正式提交”，如果所有参与者都回答yes，则向所有参与者发起commit;否则，向所有参与者发起rollback。
因此，要实现2pc，所有参与者都得实现3个操作：prepare/commit/rollback。

2pc的实现
关于2pc，对应的实现层面，也就是XA协议或使用DB_LINK;

2pc的问题
阶段2：其中一个参与者超时或者出错（1、操作异常终止；2、一半事务成功，一半事务失败；3、网络抖动。），那其他参与者，是commit，还是rollback？也不能确定。

1、查看数据库的等待事件
col inst_id for 99;
set lines 2000;
set pages 2000;
select INST_ID,event,count(1) from gv$session where event like ‘enq%’ group by event,INST_ID order by 3;

INST_ID EVENT COUNT(1)

  1 enq: TX - row lock contention                      1

可以看到有一个行锁
2、查找数据库锁：REQUEST等于0的是持有锁者，REQUEST大于0的是持有锁者
set lines 2000;
set pages 2000;
col sess for a20
SELECT /+ rule/DECODE(request,0,'Holder: ',‘Waiter: ‘)||sid||’,Inst:’||inst_id sess,
id1, id2, lmode, request, type
FROM gV$LOCKWHERE(id1,id2,type)IN(SELECTid1,id2,typeFROMV$LOCK WHERE request>0)
ORDER BY id1, request;
SESS ID1 ID2 LMODE REQUEST TY

---

Holder: 1,Inst:1 589837 887 6 0 TX
Waiter: 43,Inst:1 589837 887 0 6 TX
1是持有者的sid； 43是被锁者的sid

提示：如果锁太多可以用以下命令分别查看持有者和被锁者
查看持有者：
set lines 2000;
set pages 2000;
col sess for a20
SELECT /+ rule/DECODE(request,0,'Holder: ',‘Waiter: ‘)||sid||’,Inst:’||inst_id sess,
id1, id2, lmode, request, type
FROM gV$LOCKWHER$