eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 《深入浅出Oracle》修订初稿定稿 | Blog首页 | 言论之:马云 与 巴菲特 »

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

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

历史上的今天...
    >> 2007-07-24文章:
    >> 2006-07-24文章:
    >> 2004-07-24文章:

无觅

By eygle on 2008-07-24 10:14 | Comments (3) | FAQ | 1985 |

3 Comments

说句题外话.

要想得到更好的系统扩展(scale out), 还是应当放弃 2PC 远程事务.

可以参考 Randy 的演讲,

Strategy 2: Async Everywhere
- "Good things come to those who wait"

At every level, decomposing the processing into stages or phases, and connecting them up asynchronously, is critical to scaling.

Best Practice #3: Avoid Distributed Transactions

http://www.infoq.com/articles/ebay-scalability-best-practices

能避免是当然好,不过很多时候是避免不了,数据库本身的很多机制也是通过分布式事务来实现的。

oracle 的 XA 没问题, 但是跟 sqlserver 组合起来的XA, 我在9i底下测试是有问题的, oracle 方能正常的滚回来, 但是 sql server 就 hangs 在那里.


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com