浅述Oracle分布式事务概念

 

随着系统的复杂性不断增加，我们所面对的分布式系统渐渐增加。分布式文件系统、分布式消息队列系统等等层出不穷，在一些行业特别是互联网行业应用广泛。分布式数据库也是目前使用比较常用的分布式系统之一。

 

简单来说，分布式数据库就是通过多个相互连接的数据库节点（注意不是Instance），来支持前端系统数据访问需要的数据库组织结构。各个节点之间相互独立、自我管理（site autonomy）。分布式数据库系统追求的主要目标包括：可用性（availability）、准确性（accuray）、一致性（concurrence）和可恢复性（recoverability）。

 

在一些横跨多部门、多数据源和多子系统的复杂系统环境下，使用和组织分布式数据库可能是一种低成本且更具有灵活性的解决方案。

 

1、从Remote Transaction到Distributed Transaction

 

数据库事务是每一个DBMS最核心关注的问题。在分布式数据库环境下，我们的事务对象可能会横跨多个数据库对象。为了保证ACID的基本事务规则，引入了分布式事务（Distributed Transaction）的概念。首先我们区分一下几个基本的事务类型：

 

ü        Local Transaction本地事务

 

SQL操作语句数据范围只是限制在本地节点上。

 

ü        Remote Transaction远程事务

 

事务中进行的增加、修改和删除数据对象，存放在远程Remote端的数据库上。本地数据库对象没有参与到事务范围中去。

 

ü        Distributed Transaction分布式事务

 

所谓分布式事务，就是事务过程中涉及到对本地和远程对象的增加、修改和删除操作。

 

这里注意一个问题，我们在这里讨论的分布式事务，是通过数据库自身特性实现的分布式事务特性。目前，很多中间件，如Jboss，都提供了中间件级别的分布式事务支持。这种情况下，中间件会向Oracle提出分布式事务管理权获取，之后的事务管理过程交付给Jboss管理。这种情况不是我们今天要讨论的分布式事务问题。

 

2、事务对象实体

 

完全的分布式事务对象是有多个角色的，具体来说有如下几个类型：

 

ü        Client（C）客户端：在分布式事务中，能够获取到远程数据库服务器上对象引用（reference）的结点对象；

 

ü        Server（S）服务器：在分布式事务中，直接被引用，或者被其他节点请求获取到数据的节点对象；

 

ü        Global Coordinator（GC）全局协调节点：是分布式事务启动的节点；

 

ü        Local Coordinator（LC）本地协调节点：引用了其他节点上的数据，来完成自身工作的节点对象。

 

ü        Commit Point Site（CPS）事务提交站点：事务涉及的节点中，具有commit_point_strength参数的站点。它通常是分布式事务中，最重要的一个站点对象。在发生“in-doublt”事务的时候，该站点是不能出现冲突的。

 

ü        Commit_point_strength：是init.ora中的一个初始化参数。用来在分布式环境中确定CPS站点。

 

 

 

SQL> show parameter commit_point;

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

commit_point_strength                integer     1

 

 

注意，上面我们提及的分布式事务涉及对象，是指涉及的节点角色。在通常的Distributed Transaction中，一个实际的node是可以充当多个角色的。

 

3、Two-Phase Commit（二阶段提交）

 

Two-Phase Commit是分布式数据库系统中一个经典事务模型，用于解决多个数据库节点之间在进行事务提交过程中的方式问题。

 

二阶段提交一共具有两个阶段，分别为准备阶段（Prepare Phase）和提交阶段（Commit Phase）。一个分布式事务，要经历两个阶段过程：

 

ü        准备阶段Prepare Phase

 

首先，事务涉及到的各个节点需要确定一个commit point site。同时，全局协调者（Global Coordinator）向所有其他的节点（除了commit point site）发消息，要求进行分布式commit或者rollback动作。

 

在GC发送消息的过程中，Local Coordinators会将这些消息传播到其依赖的节点上。保证消息可以传到分布式事务涉及到的所有节点对象。

 

对这些被通知到的节点而言，可能的反馈结果有三个：prepared、abort和read-only nodes。

 

注意，如果在这个过程中，有节点发出abort过程，整个过程就转入到全局rollback过程。

 

在反馈结果中，各个节点同时将自己的SCN号发送到Global Coordinator节点。GC来确定出各节点中最大的事务SCN号。

 

经过了prepared phase，我们就可以进入到commit phase阶段。在prepared phase结束一直到commit phase成功结束期间，除了在commit point site上进行的事务外的其他事务都进入所谓的“in-doubt”状态。

 

ü        提交阶段commit phase

 

GC向commit point site通知到对比完的最大的SCN编号。此时，Commit Point Site将进行commit动作或者rollback动作。注意，此时在cps上的锁被释放掉。

 

如果CPS成功的进行过commit或者rollback动作，它会通知到Global Coordinator进行提交的时间点。

 

该通知会通过GC/LC的传导机制，传导到所有的节点进行commit/rollback动作。

 

 

如果所有的过程全都成功结束，每个语句都在使用相同的SCN进行提交。之后，RECO进程开始进行分布式事务清理过程，清理在“dba_2pc_pending”和“dba_2pc_neighbors”中相应的信息。之后，各个节点进入了“forget”阶段，开始“忘记”事务信息。

 

ü        忘记阶段forget phase

 

当全部参与分布式事务的节点都完成了相应的commit或者rollback操作，它们就会通知到commit point site，告知当前事务操作结果。Commit point site就可以forget事务信息了。

 

各个节点通信并不是直接同cps进行，而是同GC。GC将结果信息告知给commit point site，之后cps将该事务的信息清除掉。

 

 

Cps在清除完事务信息之后，通知GC自身已经清楚了分布式事务状态。GC之后就清楚自身上的事务信息。

 

 

4、结论

 

本文是一片纯理论介绍的文章，介绍了Oracle分布式事务模型的内容。

 

 

参考文献：mos 13229.1

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-716756/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-716756/