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

最新推荐文章于 2024-08-17 23:48:15 发布

yfleng2002

最新推荐文章于 2024-08-17 23:48:15 发布

阅读量1.9k

点赞数

分类专栏： ORACLE

ORACLE 专栏收录该内容

113 篇文章 1 订阅

订阅专栏

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

0

作者： eygle | English Version 【转载时请以超链接形式标明文章出处和作者信息及本声明】
链接： 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.