浅述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分布式事务模型的内容。

 

声明：本文转自http://blog.itpub.net/23890223/viewspace-722195/，仅供学习使用。