在WebSphere Federation Server版本9.1中使用联合两阶段提交处理分布式事务-CSDN博客

联合系统是一种分布式数据库管理系统，使用户能够在不同的数据源环境中访问数据，就像所有数据都驻留在单个数据库中一样。联合事务是一种事务，包括对联合系统中一个或多个联合数据源的读取或写入访问。本文介绍了联邦两阶段提交，这是WebSphere Federation Server版本9.1中的一项新功能，可在联邦事务中提供多站点更新功能。

为什么要进行联邦两阶段提交？

合并，收购，旧产品和高可用性要求通常意味着数据驻留在给定组织内不同系统中的多个数据库中。因此，应用程序可能需要在单个事务中读取和更新多个数据库中的数据。两阶段提交可确保这种类型的多站点更新数据库访问的事务完整性。

以资金转移活动为例。假设某人想将钱从支票帐户转移到她的储蓄帐户并接收交易记录。如果支票帐户数据库位于Oracle服务器上，则储蓄帐户数据库位于DB2®for z / OS服务器上，并且事务历史记录表位于DB2 Linux，UNIX®和Windows®服务器（多站点）上为了保持事务的原子性，必须进行更新。换句话说，应用程序必须在单个交易中借入支票账户，贷记储蓄账户并更新交易历史表。如果这些更新中的任何一个失败，则必须撤回整个事务。否则，数据将不一致。

许多组织在遗留系统上都有大型机应用程序。您如何从这些大型机应用程序读取或写入驻留在一个或多个数据源上的数据？假设您在大型机上有一个CICS应用程序，该应用程序需要读取或更新Oracle服务器上的表对象以及其他任务。以前，WebSphere®Federation Server使您能够从大型机上的CICS应用程序读取Oracle数据。借助联合的两阶段提交功能，大型机应用程序还可以通过WebSphere Federation Server更新DB2和非DB2数据源。在WebSphere Federation Server环境中，应用程序可以在一个工作单元中更新一个或多个同构或异构数据源。

联邦两阶段提交设计

在纯DB2环境中（将FEDERATED数据库管理器配置参数设置为no ），用于Linux，UNIX和Windows服务器的DB2支持XA两阶段提交协议。它作为XA资源管理器参与由外部XA兼容事务管理器管理的全局事务。用于Linux，UNIX和Windows服务器的DB2还支持分布式关系数据库体系结构（DRDA）两阶段提交协议。它在DB2协调的事务中充当DB2事务管理器或DB2资源管理器。

在联邦环境中（将FEDERATED数据库管理器配置参数设置为yes ），WebSphere Federation Server将两阶段提交支持扩展到联邦数据源，以用于全局XA事务和DB2协调的事务。另外，WebSphere Federation Server还支持对CONNECT Type 1入站连接下的联合数据源进行隐式两阶段提交。

联合两阶段提交为访问一个或多个联合数据源的联合事务提供了两阶段提交功能。此功能使用行业标准X / Open XA协议来管理和协调联邦两阶段提交数据源之间的分布式事务处理。 WebSphere Federation Server充当这些联合数据源的XA事务管理器。

两阶段提交协议包括准备阶段和提交阶段。在准备阶段，WebSphere Federation Server向参与当前事务的联合两阶段提交数据源发送PREPARE请求，然后等待答复。如果一切顺利，则在提交阶段，WebSphere Federation Server将COMMIT消息发送到联合的两阶段提交数据源，以等待事务结果。

此过程类似于DB2 Linux版，UNIX版和Windows Information Center的两阶段提交部分中描述的过程。

在分布式环境中，联邦系统上可以配置数十个或数百个数据源。为了最大程度地减少恢复开销以及在发生故障时保留的资源和对所有数据源的锁定，联合两阶段提交设计采用了假定的无协议，并对联合环境进行了其他优化。在联合两阶段提交过程开始时，将标识当前事务的所有联合两阶段提交参与者的强制日志记录写入磁盘。强制日志记录要求在进行事务之前将记录写入磁盘。在第二阶段结束时，将单个“忘记”日志记录写入磁盘，以表示事务已完成。

图1说明了具有CONNECT Type 1入站连接的联邦事务的常规两阶段提交流程，该事务涉及两个联邦两阶段提交数据源RM1和RM2的更新。在这种情况下，三个事务日志记录被写入联邦数据库：FedPrepare日志记录表示联邦两阶段提交过程的开始；提交日志记录表明准备阶段的事务结果为提交；并且“忘记日志”记录表示当前交易已完成。本文后面的部分将讨论不确定事务和重新同步。

图1：具有一阶段提交入站连接的联合两阶段提交流程

在准备阶段，如果来自联合两阶段提交数据源的所有答复均表示为只读，并且对联合服务器本身未执行任何更新，则联合事务是只读事务。在这种情况下，在联合服务器上写入了两个事务日志记录：FedPrepare日志记录和“忘记”日志记录。在这种情况下，将跳过提交日志记录。

配置和事务角色

WebSphere Federation Server的所有三种配置类型都支持联合两阶段提交：

通过一阶段落实连接连接到WebSphere Federation Server的应用程序
通过DB2协调的两阶段提交连接连接到WebSphere Federation Server的应用程序
通过XA连接连接到WebSphere Federation Server的应用程序

使用单阶段提交连接（在DB2系列中也称为CONNECT（类型1）），应用程序只能连接到工作单元中的一台DB2服务器并对其进行访问。在本文的上下文中，此DB2服务器是指联合服务器。在此配置中，WebSphere Federation Server扮演内部事务管理器的角色，该事务管理器负责协调联合服务器和联合两阶段提交数据源之间的两阶段提交操作。应用程序可以针对联合两阶段提交数据源以及联合服务器执行多站点更新。图2显示了一个DB2 Linux，UNIX，Windows客户机，该客户机在WebSphere Federation Server上更新了一个本地表，在数据源1上加入了DB2 Linux，UNIX，Windows昵称，在数据源3上加入了Oracle昵称，并在数据上更新了Oracle昵称。来源2：

图2：一阶段提交连接环境中的联合配置

使用DB2协调的两阶段提交连接（在DB2系列中也称为CONNECT（类型2）），应用程序可以连接到一个工作单元中的多个DB2服务器并对其进行访问。这也称为DB2协调的两阶段提交。在本文的上下文中，这些DB2服务器之一是指WebSphere Federation Server。在这种配置中，WebSphere Federation Server扮演两个角色：一方面，它是联邦两阶段提交数据源的子事务管理器；另一方面，它是联合两阶段提交数据源的子事务管理器。另一方面，它是其他DB2服务器的DB2事务管理器，还是DB2事务管理器的DB2资源管理器。图3显示了使用CONNECT（类型2）预编译的应用程序，它通过WebSphere Federation Server访问数据源1上的Oracle昵称，数据源2上的DB2 z / OS昵称和数据源3上的Informix昵称：

图3：DB2协调的两阶段提交连接环境中的联合配置

在XA分布式事务处理（DTP）环境中，WebSphere Federation Server可以作为XA资源管理器参与由XA兼容事务管理器协调的全局事务。在这种配置中，WebSphere Federation Server扮演两个角色：一方面，它是联邦两阶段提交数据源的子事务管理器；另一方面，它是联合两阶段提交数据源的子事务管理器。另一方面，它是外部XA兼容事务管理器的资源管理器。图4显示了一个MQ应用程序，该应用程序访问数据源1上的Informix昵称，数据源2上的Oracle昵称，以及数据源3上的DB2 Linux，UNIX和Windows昵称。在此示例中，WebSphere MQ充当外部XA事务管理器，而WebSphere Federation Server充当WebSphere MQ的XA资源管理器，还充当数据源1，数据源2和数据源3的子事务管理器。

图4：XA DTP环境中的联合配置

启用联合两阶段提交

设置数据源以在XA两阶段提交环境中工作之后，可以使用DB2_TWO_PHASE_COMMIT服务器选项在联合数据库中为该数据源启用联合两阶段提交功能。默认情况下，此服务器选项是禁用的。要为所有联合用户的数据源永久启用联合两阶段提交功能，可以通过CREATE SERVER语句或ALTER SERVER语句激活DB2_TWO_PHASE_COMMIT服务器选项。要在用户或应用程序与联邦数据库建立连接期间临时为数据源启用功能，可以通过SET SERVER OPTION语句激活服务器选项。

还提供了XA_OPEN_STRING_OPTIONS服务器选项，以允许向某些数据源的联合xa_open调用提交其他信息。

请参阅为联合事务启用两阶段提交以获取更多详细信息。

事务错误恢复和重新同步

第一阶段错误

在联合环境中，在以下情况下可能会发生第一阶段错误：

在编写FedPrepare日志之后和发出PREPARE请求之前，WebSphere Federation Server遇到错误。
一个或多个联合数据源在将FedPrepare日志记录写入数据源侧之前或之后遇到错误。
通讯错误。
WebSphere Federation Server在确定事务结果之前遇到错误。

在第一阶段中，如果任何数据源遇到错误，那么WebSphere Federation Server将停止向其他参与数据源发送PREPARE请求，因为事务结果是已知的。任何第一阶段错误都会导致ROLLBACK结果。因此，WebSphere Federation Server继续将ROLLBACK事务请求发送到当前事务中的所有参与数据源。

第二阶段错误

在联合环境中，在以下情况下可能会发生第二阶段错误：

WebSphere Federation Server在写入Commit日志记录之后和传递提交结果之前遇到错误。
一个或多个数据源在写入提交日志记录之前或之后遇到错误。
通讯错误。
联盟在写入“忘记日志”记录之前遇到错误。

在第二阶段中，如果任何数据源遇到错误，那么WebSphere Federation Server会记住该故障，并继续将事务结果传递给其余参与的数据源，直到第二阶段结束为止。那时，WebSphere Federation Server指示需要重新同步。通过这种设计，只要WebSphere Federation Server保持运行状态，RESYNCHRONIZATION请求就只会发送到遇到错误的数据源。它不会发送到参与事务的所有数据源，以使受影响的数据源的数量保持最少。

处理错误

联合事务处理通过以下方式处理这些错误中的每一个：

第一阶段错误：如果WebSphere Federation Server或任何参与的数据源无法成功准备事务，则事务结果变为ROLLBACK，并且WebSphere Federation Server向所有参与的数据源发送ROLLBACK请求，以等待事务结果。
第二阶段错误：确定交易结果并将其记录在WebSphere Federation Server上之后，随后发生的任何错误都不会更改交易结果。
如果一个或多个参与的数据源未能提交（当事务结果为COMMIT时）或回滚失败（当事务结果为ROLLBACK时），那么WebSphere Federation Server将通过称为重新同步的过程将事务结果重新传送给失败的数据源。 WebSphere Federation Server不会对联合数据源发出xa_recover call 。 xa_recover call从资源管理器获取准备好的事务分支的列表。相反，WebSphere Federation Server通过称为重新同步的过程与联合数据源同步。

重新同步

不确定事务是处于不确定状态的全局事务。在以下任何一种情况下，联合事务都可能在联合数据库站点上变得不确定：

在全局XA事务中，当成功完成第一阶段或PREPARE阶段后，外部XA事务管理器或WebSphere Federation Server不可用时。
在DB2协调的事务中，当成功完成第一阶段后DB2事务管理器或DB2资源管理器不可用时。如前所述，WebSphere Federation在此环境中可以充当DB2事务管理器或DB2资源管理器。
在这三个入站连接环境中的任何一个中，当成功完成第一阶段之后，当WebSphere Federation Server或联合的两阶段提交数据源中的至少一个变得不可用时。

重新同步过程将尝试完成所有不确定事务，即已完成第一阶段但未完成第二阶段的事务，并且将提交或回滚。在此过程中，WebSphere Federation Server连接到每个不确定事务中涉及的数据源，然后重新发送事务结果。在所有数据源完成事务之后，WebSphere Federation Server将此不确定事务标记为完成。如果任何数据源都无法完成事务，那么WebSphere Federation Server将在下一个时间间隔内重试重新同步过程。默认间隔为180秒。数据库管理器RESYNC_INTERVAL配置参数控制WebSphere Federation Server在尝试提交或回滚这些不确定事务之间等待的时间。

在Linux，UNIX和Windows的DB2版本9的resync_interval-事务重新同步间隔配置参数部分中找到有关RESYNC_INTERVAL配置参数的更多详细信息。

注意：如果事务由符合XA的事务管理器协调，则由事务管理器来启动重新同步。

手动恢复不确定交易

如果您无法等待重新同步过程自动解决不确定事务，则WebSphere Federation Server支持手动恢复不确定事务。此过程有时称为启发式处理。与DB2不确定事务相比，联邦不确定事务可以分为两个附加的事务状态：

缺少联邦COMMIT确认状态：联邦事务结果是已知的（COMMIT）。WebSphereFederation Server尚未从一个或多个联邦数据源收到COMMIT确认。
缺少联合的ROLLBACK确认状态：联合的事务结果是已知的（ROLLBACK）。 WebSphere Federation Server尚未从一个或多个联合数据源收到ROLLBACK确认。

您可以试探性地提交状态缺少联合的COMMIT确认的事务，也可以试探性地回滚其状态缺少联合的ROLLBACK确认的事务。但是，由于事务结果已经确定，因此您不能试探性地提交状态缺少联合ROLLBACK确认的事务，也不能执行相反的操作。

有三种方法可以对联合不确定事务执行启发式处理：

使用list indoubt transactions命令
通过不确定事务管理器GUI
通过启发式API，其中提供了一组API来查询，提交和回滚不确定事务，并取消通过启发式提交或回滚的事务

性能考量

与未启用的源相比，为联合的两阶段提交启用远程源会产生以下额外的日志记录和通信开销：

在WebSphere Federation Server上进行其他数据库日志写入（所有事务，包括只读事务和仅涉及一个源的事务）
其他数据库日志写入数据源（更新事务，即使它们仅涉及一个源）
WebSphere Federation Server与数据源之间的其他通信（所有事务）

重要的是要认识到，为远程源启用联合两阶段提交会使所有涉及该源的事务经历上述处理，I / O和网络开销。这不仅适用于需要两阶段提交的事务。您仅应在需要两阶段提交语义的应用程序中为数据源临时启用联合两阶段提交。以这种方式启用的联合两阶段提交在应用程序与联合数据库的连接期间一直处于活动状态。通过持久服务器选项永久性地为数据源启用联合两阶段提交意味着即使使用该源的所有联合应用程序都不需要支持多站点更新，也都可能产生联合两阶段提交的潜在开销。

对于不需要联邦两阶段提交的事务，与联邦两阶段提交相关的开销（经过时间和资源使用的增加）是恒定的，并且与基础事务的性质或持续时间无关。因此，对于较短的事务，开销比较明显，而对于较长的事务，开销不太明显。同样，您应该通过仅在实际需要该功能的应用程序中启用联合两阶段提交来最大程度地减少任何不必要的开销。

最小化联合两阶段提交开销的一个非常重要的因素是在联合服务器上选择日志设备。由于联合两阶段提交涉及对日志的其他写入，因此将联合服务器日志文件放置在具有快速写入缓存的高性能磁盘上具有相当大的优势。快速写入缓存提供了一个内存区域，该内存区域允许延迟和批处理I / O。当然，写高速缓存必须保证对高速缓存所做的写操作的持久性，这意味着它们最终必须写到持久性磁盘介质上。

性能测试表明，当在联邦服务器上使用具有快速写入缓存的日志磁盘而不是没有写入缓存的简单SCSI设备时，涉及启用了联合两阶段提交的源的事务的总吞吐量将提高40％左右。

高可用性灾难恢复支持

DB2 Linux，UNIX和Windows高可用性灾难恢复（HADR）是一种数据库复制功能，它为站点故障提供了高可用性解决方案。 HADR通过将数据更改从源数据库（称为主数据库）复制到目标数据库（称为备用数据库）来防止数据丢失。无论入站连接类型如何，联合服务器都为启用了HADR功能的Linux，UNIX和Windows版本8.2及更高版本的数据源提供DB2自动客户端重新路由支持。

自动客户端重新路由是一种用于Linux，UNIX和Windows的DB2功能，该功能允许客户端应用程序从与服务器的通信中断中恢复，从而使应用程序能够以最小的中断来继续其工作。图5说明了启用了自动客户端重新路由功能的WebSphere Federation Server访问配置了HADR功能的联合数据源。

图5：联合两阶段提交和HADR

故障排除技巧

WebSphere Federation Server版本9.1中受支持的数据源和包装器模式

在这些数据源中，使用WebSphere Federation Server版本9.1中的受信任包装器支持联合两阶段提交：

DB2 z / OS版，DB2 iSeries版，DB2 Linux版，UNIX版和Windows版
Informix
Oracle
Sybase公司
Microsoft（MS）SQL Server

为了支持Sybase和MS SQL Server，必须在Windows平台上安装WebSphere Federation Server。

DB2 for z / OS和DB2 for iSeries数据源的注意事项

创建用于Linux，UNIX和Windows的DB2实例后，将使用默认设置自动配置DB2同步点管理器（SPM）。 SPM是DB2数据源所需的DB2 Connect功能的组件，该数据源尚不支持DRDA中的本机XA流，但确实支持DRDA两阶段提交流。 DB2 z / OS版和DB2 iSeries版5.3或更早版本属于此类别。 SPM在XA和DRDA两阶段提交流之间执行映射。缺省情况下，DB2实例具有SPM配置参数的预定义值。最重要的参数是SPM_NAME数据库管理器配置参数。如果您的联合应用程序在尝试以两阶段提交设置访问DB2 for z / OS数据时遇到通信协议错误，请验证SPM_NAME是否正确设置。

通过SPM提供联合两阶段提交访问时，由于联合支持与SPM之间不兼容，因此不支持所有XA语义。例如，事务不能嵌套。在开始新事务之前，必须提交或回退所有事务。

使用外部XA兼容事务管理器访问DB2 for z / OS或DB2 for iSeries数据源的注意事项

一些符合XA的事务管理器的体系结构可能具有来自不同流程的提交序列。 DB2 Connect连接集中器技术允许应用程序保持连接状态，而不会消耗DB2主机服务器上的任何资源。当要更新DB2 for z / OS或DB2 for iSeries版本5.3数据库服务器时，必须启用DB2 Connect连接集中器以支持来自XA兼容事务管理器（例如，WebSphere MQ）的不同进程的提交序列。当前，不能同时启用连接集中器和联合功能。为了促进此类外部XA兼容事务管理器在联合两阶段提交环境中访问DB2 for z / OS或DB2 for iSeries版本5.3和较低数据源，在以下情况下需要DB2 Connect跃点（已激活连接集中器） WebSphere Federation Server和DB2 for z / OS以及DB2 for iSeries数据源。图6说明了这样的配置，其中WebSphere MQ充当外部XA事务管理器。

图6：WebSphere Federation Server和DB2 Connect（集中器和SPM）配置

这是两种类型的应用程序，其中连接集中器与联合两阶段提交一起使用：

Application 1:
xa_open
xa_start tx A
   Federated work
xa_end tx A

Application 2:
xa_open
xa_prepare tx A

集中器的典型用法是允许多个入站连接重用出站连接。示例1说明了一个场景，其中就提交处理而言，单个事务上有多个入站连接。这两个入站连接必须使用与z / OS或iSeries数据库相同的出站连接，因为它们都处理事务tx A 通过启用连接集中器，这变得可行。这在XA DTP环境中特别有用，在该环境中，外部XA兼容事务管理器支持来自不同进程的提交序列。

xa_open
xa_start tx A
   Federated work
xa_end tx A
xa_start tx B

在示例2中，有一个入站连接，但有多个出站连接，每个都用于一个正在进行的事务。交易tx A就是xa结束，但还没有提交，或当交易回滚tx B开始。事务tx B需要不同的出站连接，而事务tx A的出站连接则被搁置。但是，到z / OS或iSeries数据库的出站连接在任何时间点都与单个事务相关联，这是DRDA两阶段提交要求。通过启用连接集中器，将启动另一个出站连接，并将其用于事务tx B 有两个连接到同一z / OS数据源的出站连接，每个事务一个。

结论

联合的两阶段提交为WebSphere Federation Server提供了位置透明性和事务原子性。联合的两阶段提交在一个事务中将对多个数据源的更新组合在一起，以便更新所有涉及的源，或者不更新任何源。此策略可确保源保持同步。此功能将进一步加快新应用程序的交付速度，并确保您的分布式环境中的数据完整性。

翻译自: https://www.ibm.com/developerworks/data/library/techarticle/dm-0611chang/index.html