使用 WebSphere 中间件构建高可用性数据库环境，第 3 部分

核心提示： 注意，如果关闭 LOAD_BALANCE 属性，使用 WebSphere 中间件构建高可用性数据库环境，第 3 部分(4)，则在数据源 URL 中指定 RAC 节点的顺序就变得非常重要，Oracle JDBC 驱动程序始终尝试从占据列表中第一位置的 RAC 节点获取物理连接，是因为在 RAC 节

注意，如果关闭 LOAD_BALANCE 属性，则在数据源 URL 中指定 RAC 节点的顺序就变得非常重要。Oracle JDBC 驱动程序始终尝试从占据列表中第一位置的 RAC 节点获取物理连接。如果第一个 RAC 节点不可用，JDBC 驱动程序将尝试从第二个 RAC 节点中获取连接，依此类推。这说明，对于 URL (1)（在清单 1 中），cluster-member1 的 URL (rac-node1) 是 RAC 主节点。只要 rac-node1 仍在正常运行，将从 rac-node1 中为所有物理连接请求提供服务；rac-node2 不起任何作用。如果 rac-node1 出现故障，Oracle 将从 rac-node2 为 cluster-member1 中发出的连接请求提供服务，rac-node2 是 URL (1) 的第二个 RAC 节点。因此，只要 rac-node1 不能用，来自 cluster-member1 中的所有新连接请求都将由 rac-node2 提供服务。

在这种情况下，图 2 中的完整工作负载管理分两个级别提供。在 WebSphere Application Server 级别，工作负载管理由路由器组件（HTTP 服务器插件、ORB 插件、按需路由器等）提供，它将入站请求分发给适当的集群成员，并维护适当的关联（如果适用）。在入站请求到达在集群成员上执行的应用程序实例后，向数据库发出的新物理连接请求将由 Oracle JDBC 驱动程序在 rac-node1 和 rac-node2 之间进行负载平衡。

如果该应用程序不使用 2PC 分布式事务，上述简单配置就足够了。但是，如果在此简单和易于配置的设置中使用 2PC 分布式事务，可能会存在一些微妙的恢复问题，这将在下一部分中进行说明。

两阶段提交分布式事务和 RAC 配置

当恢复跨多个 Oracle RAC 节点的 2PC 分布式事务时，Oracle 10g RAC 存在一个固有的问题：在尝试提交或回滚以前在故障 RAC 节点中运行的事务分支（通过活动 RAC 节点）时，事务管理器可能会收到这样一条异常消息“ORA-24756:transaction does not exist”（ORA-24756：事务不存在）。之所以会发生此问题，是因为在 RAC 节点出现故障时，Oracle 将为业务打开其他仍然运行的 RAC 节点，即使在 Oracle RAC 完成与该故障 RAC 节点对应的必要恢复操作之前也如此。