浅述Oracle分布式事务概念

转：http://space.itpub.net/?uid-17203031-action-viewspace-itemid-716756

 

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

 

简单来说，分布式数据库就是通过多个相互连接的数据库节点（注意不是 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