[Oracle] 分布式事务和两阶段提交(2PC)

[Oracle] 分布式事务和两阶段提交(2PC)

分布式事务是指发生在多台数据库之间的事务，Oracle中通过dblink方式进行事务处理，分布式事务比单机事务要复杂的多。大部分的关系型数据库通过两阶段提交（2 Phase Commit 2PC）算法来完成分布式事务，下面重点介绍下2PC算法。

1、分布式事务的组成

在分布式事务中，主要有以下几个组成部分：

• Client：调用其它数据库信息的节点
• Database：接受来自其它节点请求的节点
• Global Coordinator (GC)：发起分布式事务的节点
• Local Coordinator (LC)：处理本地事务，并和其它节点通信的节点
• Commit Point Site (CPS)：被Global Coordinator指定首先提交或回滚事务的节点

 

在分布式事务中，Commit Point Site非常重要，它不需要进入2PC的Prepared 状态，因为它通常操作最关键数据，所以它不会出现in-doubt状态。Commit Point Site总是优先于其它数据库节点先提交，目的在于保护最关键的数据，它决定整个分布式事务是提交还是回滚。分布式事务中其它数据库节点在GC的指挥下进行后续的提交（或回滚）。

那么在Oracle中如何选取Commit Point Site呢？它是根据参数commi_ point_strength 最大的数据库作为Commit Point Site。

2、两阶段提交(2PC)

两阶段提交协议可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某些情况下它还需要人为的参与才能解决问题。

 

顾名思义，两阶段提交分为以下两个阶段：

1）Prepare Phase （准备节点）

2）Commit Phase （提交阶段）

1）Prepare Phase

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

 

为了完成准准备阶段，除了commit point site外，其它的数据库节点按照以下步骤执行：

• 每个节点检查自己是否被其它节点所引用，如果有，就通知这些节点准备提交（进入 Prepare阶段）。
• 每个节点检查自己运行的事务，如果发现本地运行的事务没有修改数据的操作（只读），则跳过后面的步骤，直接返回一个read only给全局协调器。
• 如果事务需要修改数据，则为事务分配相应的资源用于保证修改的正常进行。
• 当上面的工作都成功后，给全局协调器返回准备就绪的信息，反之，则返回失败的信息。

2) Commit Phase

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

 

提交阶段按下面的步骤进行：

• 全局协调器通知 commit point site 进行提交。
• commit point site 提交，完成后通知全局协调器。
• 全局协调器通知其它节点进行提交。
• 其它节点各自提交本地事务，完成后释放锁和资源。
• 其它节点通知全局协调器提交完成。

3）结束阶段

• 全局协调器通知commit point site说所有节点提交完成。
• commit point site数据库释放和事务相关的所有资源，然后通知全局协调器。
• 全局协调器释放自己持有的资源。
• 分布式事务结束

一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。

唯一一个两阶段提交不能解决的困境是：当协调者在发出commit 消息后宕机，而唯一收到这条命令的一个参与者也宕机了，这个时候这个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他节点也最终会收到commit 的信息。这也符合CAP理论。

更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

===============================================================

2PC、XA、DTP与两阶段提交

2

作者： eygle | English  【转载时请标明 出处和作者信息】|【 恩墨学院 OCM培训传DBA成功之道】
链接： http://www.eygle.com/archives/2008/07/2pc_xa_dtp.html

站内相关文章|Related Articles

数据字典视图之：v$session 结构
DBA手记:X$KTUXE与Oracle的死事务恢复
大事务回滚导致系统故障案例一则
数据字典视图之:V$ENQUEUE_STATISTICS 结构
数据字典视图之:V$LATCH_CHILDREN 结构

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规范的基础是两阶段提交协议。 

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

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

在Oracle数据库中，可以通过运行xaview.sql （位于ORACLE_HOME/rdbms/admin目录下）创建相关的视图。
这个脚本的信息如下：

Rem ==================================================================
Rem NAME
Rem  XAVIEW.SQL
Rem FUNCTION
Rem  Create the view necessary to do XA recovery scan of prepared
Rem  and heuristically completed transactions.
Rem NOTES
Rem  The view 'XATRAN' basically combines information from two
Rem  different types of tables:
Rem      pending_trans$ & pending_sessions$
Rem      x$k2gte2
Rem  The view v$pending_xatrans$ combines and then filters information
Rem  from the table pending_trans$ and pending_sessions$ into format
Rem  that satisfy XA criteria.
Rem  Then the view v$xatrans$ combines information from x$k2gte2 and
Rem  v$pending_xatrans$.
Rem MODIFIED
Rem    ncramesh  08/04/98 - change for sqlplus
Rem  cchew    07-15-92  - added fmt column
Rem  cchew    05-22-92  - No more fmt=0 condition
Rem  cchew    01-19-92  - Creation
Rem ==================================================================


DROP VIEW v$xatrans$;
DROP VIEW v$pending_xatrans$;


CREATE VIEW v$pending_xatrans$ AS
(SELECT global_tran_fmt, global_foreign_id, branch_id
  FROM  sys.pending_trans$ tran, sys.pending_sessions$ sess
  WHERE  tran.local_tran_id = sess.local_tran_id
    AND    tran.state != 'collecting'
    AND    BITAND(TO_NUMBER(tran.session_vector),
                  POWER(2, (sess.session_id - 1))) = sess.session_id)
/

CREATE VIEW v$xatrans$ AS
(((SELECT k2gtifmt, k2gtitid_ext, k2gtibid
  FROM x$k2gte2
  WHERE  k2gterct=k2gtdpct)
MINUS
  SELECT global_tran_fmt, global_foreign_id, branch_id
  FROM  v$pending_xatrans$)
UNION
SELECT global_tran_fmt, global_foreign_id, branch_id
  FROM  v$pending_xatrans$)

/

Oracle XA是Oracle实施的X/Open Distributed Transaction Processing (DTP) XA接口 。ORACLE XA随软件发布，不需要独立安装部署。

Specific to XA, Oracle Database10g Release 2 provides services that are optimized to support Distributed Transaction Processing (DTP). This feature optimizes XA transaction recovery. All the in-flight prepared transactions belonging to a DTP service of the failed instance are pushed to the disk table before the DTP service is re-started on the any of the surviving instances. In-flight transaction prepare info is written to the undo area and only if the transaction fails, this information is pushed into the appropriate system table to allow external recovery to take place. During normal operations, this push is done lazily. But as soon as the DTP service fails over users expect the failed (prepared) distributed transaction info on the system table to able to recover the transaction. Thus we make sure all the required information is propagated to the system tables before starting the DTP service on one of the surviving instances. This ensures that all the in-doubt transactions will be reported by xa_recover() and a following xa_commit() or,xa_rollback() will be able to complete the in-doubt transactions. This feature also guarantees that all branches of single global distributed transactions are maintained at a single RAC instance.
This mechanism optimizes the XA recovery by recovering the transactions once, at speed, as part of the transaction recovery code. The XA/DTP feature also guarantees correctness by ensuring that all branches of a transaction are maintained at the same database instance. This includes switch over and failover of services for planned and unplanned outages. The feature is only available for services declared as DTP.

参考文档：
http://www.oracle.com/technology/products/database/clustering/pdf/bestpracticesforxaandrac.pdf

参考：

Oracle 分阶段提交 百度