2PC

2PC是指Oracle的两阶段提交协议（Two-Phase Commit protocol）。
2PC用于确保所有分布式事务能够同时提交（Commit）或者回滚（Rollback），以便使的数据库能够处于一致性状态（consistent state）。
分布式事务可以通过DBA_2PC_PENDING 和 DBA_2PC_NEIGHBORS 字典视图查看。

分布式事务处理是指一个事务可能涉及多个数据库操作
分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务必须产生一致的结果（全部提交或全部回滚）。

XA是X/Open DTP组织（X/Open DTP group）定义的两阶段提交协议，XA被许多数据库（如Oracle和DB2）和中间件等工具(如CICS 和 Tuxedo).本地支持 。
X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。在这个模型中，通常事务管理器（TM）是交易中间件，资源管理器（RM）是数据库，通信资源管理器（CRM）是消息中间件。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA接口函数由数据库厂商提供。通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。

在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于锁定状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。

在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚

DBA_2PC_PENDING
Oracle会自动处理分布事务，保证分布事务的一致性，所有站点全部提交或全部回滚。一般情况下，处理过程在很短的时间内完成，根本无法察觉到。
但是，如果在commit或rollback的时候，出现了连接中断或某个数据库站点CRASH的情况，则提交操作可能会无法继续，此时DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中会包含尚未解决的分布事务。 对于绝大多数情况，当恢复连接或CRASH的数据库重新启动后，会自动解决分布式事务，不需要人工干预。只有分布事务锁住的对象急需被访问，锁住的回滚段阻止了其他事务的使用，网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时，才使用人工操作的方式来维护分布式事务。 手工强制提交或回滚将失去二层提交的特性，Oracle无法继续保证事务的一致性，事务的一致性应由手工操作者保证
使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自动解决分布事务，即使网络恢复连接或者CRASH的数据库重新启动。
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。

Oracle解决异布lock的方法！
通常由于网络的不稳定或则数据库的bug，在使用dblink时产生了异步lock，下面就谈谈异步lock的解决方法：
1）查询 dba_2pc_pending ，确定异步lock当前的状态。
select local_tran_id, global_tran_id, state, mix, host, commit#  fromdba_2pc_pending;

LOCAL_TRAN_ID|GLOBAL_TRAN_ID        |STATE    |MIX|HOST      |COMMIT#
-------------|----------------------|---------|---|----------|-------
1.10.255     |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|202241
             |89f6eafb.1.10.255     |         |   |NT/bel449 |

此时通过state=committed, 表示此session已提交,只是在提交后，接受不到global session的transaction信息了,所以产生异步lock，此时对一般不造成table的lock。
通过调用 execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255'）； 可解决此问题。
当然state还有以下几种状态：
collecting:在收集数据过程中,产生异常
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');

prepared： 在接受到异步commit/rollback指令前， 产生异常
解决方法： rollback force tran_id/commit force tran_id; -- 可根据异步transaction的状况决定使用方法。

forced rollback：在使用rollback force出现
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');

forced commit：在使用commit force出现
解决方法： execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.10.255');

** NOTE1: If using Oracle 9i or later and DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY fails with
   ORA-30019: Illegal rollback Segment operation in Automatic Undo mode, use the following workaround

SQL> alter session set "_smu_debug_mode" = 4;
SQL>execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('local_tran_id');

测试 :
模拟的是分布式事务在2pc提交过程产生in-doubt 的问题解决方式
环境：orcl(ORCL01.TEST.COM),solo(ORCL02.TEST.COM) version 10.2.0.3
15:45:29sys@SOLO> drop public database link solo_link;

数据库链接已删除。

15:45:57sys@SOLO>  create public database link solo_link connect to scott identified by scott using 'solo';

数据库链接已创建。

15:46:18sys@SOLO> updateemp@solo_linkset sal=sal*2 ;

15:46:38sys@SOLO> commit;
如果这个时候solo出现网络故障。orcl执行commit 被挂起，这个时候如果网络恢复则问题会自动解决。
而这时如果却执行了一个shutdown abort
再启动之后,这个时候查询scott.emp表会报错：
ERROR at line 1:
ORA-01591: lock held by in-doubt distributed transaction 5.32.251

这个时候查询dba_2pc_pending数据字典会看到5.32.251 的state是prepared
并且同过查询dba_2pc_neighbors知道该事务对应的database是pu_link.test.com对应的数据库
SQL> col local_tran_id format a13
SQL> col global_tran_id format a30
SQL> col state format a8
SQL> col mixed format a3
SQL> col host format a10
SQL> col commit# format a10
SQL> select local_tran_id, global_tran_id, state, mixed, host, commit#
2 from dba_2pc_pending;
LOCAL_TRAN_ID GLOBAL_TRAN_ID                            STATE       MIX   HOST       COMMIT#
--------------------   ------------------------------------------     --------      ---    ----------   ----------
5.32.251               ORCL.TEST.COM.8705ca3e.5.32.251  prepared         no    dg1          498537

SQL> col local_tran_id format a13
SQL> col in_out format a6
SQL> col database format a25
SQL> col dbuser_owner format a15
SQL> col interface format a3
SQL> select local_tran_id, in_out, database, dbuser_owner, interface
2 from dba_2pc_neighbors;

LOCAL_TRAN_ID IN_OUT DATABASE                  DBUSER_OWNER    INT
--------------------    --------- -------------------------     ------------------          ---
5.32.251             in                                                SYS                           N
5.32.251               out         PU_LINK.TEST.COM     SYS                           C

 

这时候就需要使用手动提交或回滚  commit或者rollback
根据state列的值prepared我们知道，orcl是prepared阶段，则solo肯定不能到commit阶段.
为了事务的一致性最好 rollback force '5.32.251';
            
select local_tran_id, global_tran_id, state, mixed, host, commit#
2 from dba_2pc_pending;

LOCAL_TRAN_ID GLOBAL_TRAN_ID                            STATE         MIX HOST       COMMIT#
-------------             -------------------------------------------       -----------     ---   ----------     ----------
5.32.251               ORCL01.TEST.COM.8705ca3e.5.32. forced rollback  no    dg1
                             251                                                      

DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('5.32.251');

转自网络