探查Weblogic JDBC Multipool 问题

问题描述 WebLogic Server MultiPool 有两种不同的类型：高可用性 MultiPool 和负载平衡 MultiPool。这两种算法互不相容，分别用于达成不同的目标。本模式提供有关这两种算法的信息。 了解不同类型的 WebLogic Server MultiPool 及相应的限制有助于避免常见故障和找到常见问题的答案。本模式为您提供某些常见问题的相关信息。本模式还概述了为 WebLogic Server 版本 8.1 SP3 / 7.0 SP5 及更高版本中的 MultiPool 实现的增强功能。为便于了解更多详细信息，还提供了我们的文档中相关阅读材料的链接。 故障排除 下面提供有关 WebLogic Server MultiPool 的背景信息，该信息有助于探查有关 MultiPool 的问题和故障： WebLogic Server MultiPool 算法 MultiPool 的限制 WebLogic Server 版本 8.1 SP3 / 7.0 SP5 及更高版本中针对 MultiPool 的增强功能 快速链接： 了解 WebLogic Server MultiPool 常见故障、常见问题及其解决办法 相关阅读材料

了解 WebLogic Server MultiPool 本小节提供有关 WebLogic Server MultiPool 及其算法、MultiPool 的数据源定义、限制以及专门针对 MultiPool 的增强功能的背景信息。 WebLogic Server MultiPool 算法  WebLogic Server MultiPool 由一组有序的 JDBC 连接池组成，可以针对高可用性或负载平衡进行配置。请参阅以下文档中对这两种情况的概述：http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (English)。 在 WebLogic Server 8.1 SP3 / 7.0 SP5 及更高版本中实现了许多增强功能，使 MultiPool 算法的智能水平得到极大提升 - 请查看增强功能，了解比较情况。但对于 WLS 8.1 SP3 / 7.0 SP5 以前的版本，如本文中所述，MultiPool 逻辑的实现非常简明。 返回页首 高可用性算法 针对高可用性配置的 MultiPool 将始终首先尝试其列表中的第一个 JDBC 池。要求 MultiPool 提供连接时，它将始终按为各池定义的顺序（即按各池在 JDBC 连接池列表中的顺序）尝试它们。如果第一个 JDBC 连接池的底层数据库出现故障，MultiPool 将仍然从第一个 JDBC 连接池获取池连接。它将通过发出在 JDBC 连接池定义的属性 TestTableName 中定义的 SQL 语句测试该连接。由于数据库不可用，因此测试将会失败。MultiPool 于是将通过新建与底层数据库的物理连接来尝试刷新该连接。由于数据库仍然有故障，因此该尝试仍将失败。此时，MultiPool 将尝试其有序列表中的下一个 JDBC 连接池。 将对每个特定的连接请求执行所有上述操作。下次为相同 MultiPool 调用 getConnection() 时，将重复执行与上述相同的步骤。所执行的逻辑是，JDBC 连接池的数据库（MultiPool 的一部分）一经恢复正常，就应下一连接请求刷新连接，并立即再次使用该数据库。MultiPool 从不会将池本身标记为有故障，除非管理员将池禁用。 这使管理员能够在底层数据库发生故障时通过禁用 JDBC 连接池来影响 MultiPool 的 Failover 机制，从而避免在第一个池中进行连接测试和重新创建连接的时间开销。可以通过控制台 (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115153 (English)) 或使用 weblogic.Admin SUSPEND_POOL 命令 (http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1296729 (English)) 将池暂停使用。数据库恢复正常后，同样可以通过控制台 (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115166 (English)) 或执行 weblogic.Admin RESUME_POOL 命令 (http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1300251 (English)) 恢复池的使用。 实现了许多针对高可用性算法的增强功能 - 请查阅增强功能。 返回页首 负载平衡算法 采用负载平衡算法的 MultiPool 以 Round Robin 方式提供其连接，各连接在为其定义的所有 JDBC 连接池之间均匀分布。如果对某个连接的连接测试失败，MultiPool 会尝试从列表中的下一个池中提供连接。以下位置提供了更多详细信息：http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (English)。 因此，负载平衡既具有在若干个池间分配负载的长处，又能够在其中一个池不可用时提供一定程度的 Failover 能力。不过，如果采用负载平衡算法，将无法控制 MultiPool 响应来自其列表中不同池的连接请求的顺序及其 Failover 的目标池。 MultiPool 的限制  若要为 MultiPool 启用高可用性算法，需要考虑一些限制和前提条件。http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1068130 (English) 中提供了详细信息。下面是对上述要点的总结： 启用 JDBCConnectionPool 上的 TestConnectionsOnReserve（MultiPool 的一部分），以便 MultiPool 可以检测到连接失败及 Failover 到列表中下一个 JDBC 连接池的必要性。 MultiPool 的名称在域配置内必须是唯一的。不应以相同名称命名 JDBC 连接池和 MultiPool，因为那样会导致 Failover 故障。 如果第一个池中的所有连接都处于使用状态，MultiPool 将不会从列表中的下一个池提供连接。只有在 MultiPool 配置中的 JDBC 连接池的数据库发生故障或某个池被暂停使用时，才会提供 Failover。不过，WebLogic Server 8.1 SP3 及更高版本中添加了一个新属性 FailoverRequestIfBusy，可以通过该属性配置 MultiPool，从而实现当某个池中的所有连接都处于使用状态时，从列表中的下一个池中提供连接。WebLogic Server 版本 8.1 SP3 及更高版本中针对 MultiPool 的增强功能中对此有更为详尽的描述。 当某个应用程序从 MultiPool 中得到了一个连接后，在该应用程序使用该连接期间，将不再为该连接执行 Failover。这是因为 MultiPool 在连接测试期间调用 getConnection() 时检测到连接失败。后面阶段出现的数据库故障需要由应用程序处理，其步骤与用于正常 JDBC 连接池的步骤相同。由于数据库崩溃或关闭时会将事务回滚，因此应用程序需要对这种情况进行处理，并重新执行相关工作。 分布式事务中不支持 MultiPool，请参阅：http://e-docs.bea.com/wls/docs81/jdbc/intro.html#1029935 (English) 和 http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_multipools.html#1105912 (English)。 由于 Oracle 不能保证在针对负载平衡配置驱动程序的情况下一个事务在同一 RAC 节点上发起和结束，因此分布式事务中不支持使用 Oracle RAC/TAF 的 MultiPool。请参阅以下位置提供的详细信息：http://e-docs.bea.com/wls/docs81/jdbc/oracle_rac.html#1053178 (English)。 在属于 MultiPool 的所有 JDBC 连接池中设置 <ConnectionCreationRetryFrequencySeconds="0">。由于针对高可用性配置的 MultiPool 正常情况下会在向数据库发出的连接请求失败后 Failover 到列表中的下一个池，因此设置连接创建重试间隔会降低效率并使 MultiPool 无法进行 Failover。请参阅以下位置提供的附加信息：http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1068305 (English)。如果对 MultiPool 的其中一个 JDBC 连接池设置了连接创建重试间隔，则会显示下面这样的错误信息：

java.sql.SQLException: Pool connect failed : weblogic.common.ResourceException: testMultiPool(myMultiPool): weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool myMultiPool to allocate to applications, please increase the size of the pool and retry.. at weblogic.jdbc.common.internal.JDBCUtil.wrapAndThrowResourceException(JDBCUtil.java:160)

返回页首  WebLogic Server 版本 8.1 SP3 / 7.0 SP5 及更高版本中针对 MultiPool 的增强功能  8.1 SP3 / 7.0 SP5 及更高版本中对 MultiPool 的高可用性算法进行了改进，提供了以下附加功能： 当 MultiPool 列表中某个 JDBC 连接池的连接测试和连接重建失败时，将自动禁用该池。如果启用了“connection test on reserve”并为 JDBC 连接池定义了 TestTableName，就可以在不对配置做任何附加更改的情况下启用此功能。 被禁用池的数据库重新恢复正常时自动进行测试，并再次启用 JDBC 连接池。若要启用此功能，请设置属性 HealthCheckFrequencySeconds。 当某个池中的所有连接都处于使用状态时 Failover 到列表中的下一个池。若要启用此功能，请将属性 FailoverRequestIfBusy 设置为 true。 使通过注册回调处理程序控制向另一个池的 Failover 及在执行 Failover 前实现初始化和配置任务成为可能。若要启用此功能，回调处理程序需要实现 weblogic.jdbc.extensions.ConnectionPoolFailoverCallback 接口。需要使用属性 ConnectionPoolFailoverCallbackHandler 指定实现类。 使通过注册回调处理程序控制对被禁用池的启用及在启用前实现初始化和配置任务成为可能。此功能将由上述 Failover 控制中提及的回调处理程序来执行。 以下位置对上述新功能做了详细描述：http://e-docs.bea.com/wls/docs81/jdbc/programming.html#1023962 (English)。以下是要在 MultiPool 上设置的相关属性（一览表）：

<JDBCMultiPool AlgorithmType="High-Availability" Name="demoMultiPool" PoolList="demoPool2,demoPool"HealthCheckFrequencySeconds="240" ConnectionPoolFailoverCallbackHandler="com.bea.samples.wls.jdbc. MultiPoolFailoverCallbackApplication"Targets="examplesServer" /> 返回页首

常见故障、常见问题及其解决办法 本小节包含有关 MultiPool 的一些常见问题和解答。  WebLogic Server MultiPool 和 Oracle RAC/TAF 哪一个更适合我？ MultiPool 和 Oracle RAC/TAF 所能提供的 Failover 能力的级别不同。依赖于 Oracle RAC/TAF 的配置，可以将一个数据库中使用的部分对象 Failover 到 Failover 节点。有关详细信息，请查阅 Oracle 站点上有关 RAC / TAF 的相关文档及 Oracle RAC (Real Application Clusters) 配置和测试模式。 RAC/TAF 是由 Oracle 提供的附加功能，需要另外付费。BEA 的 MultiPool（针对高可用性配置）是 WebLogic Server 分发的一部分，其费用已包括在内。它提供建立 JDBC 连接池列表的功能，并尝试为连接池提供连接。如果一个数据库发生故障，它会尝试列表中的下一个池。它无法将故障数据库中的任何对象 Failover 到 Failover 实例。 使用某个方案而不使用另一个方案要视所需的 Failover 透明度级别和可以承受的资金开销而定。如果从池中得到连接时数据库已发生故障，MultiPool 功能对应用程序就是透明的。之后就不是透明的了。如果连接正由某个应用程序使用，则该应用程序需要处理回滚和 Failover（及重新执行工作）。  高可用性算法如何决定使用 MultiPool 列表中哪个连接池中的连接？  MultiPool 将始终按为其定义的 JDBC 连接池顺序尝试从连接池提供连接。这意味着对于每个连接请求，MultiPool 都将先尝试从第一个池提供连接，如果失败，则会尝试第二个池，如果仍然失败，则会尝试第三个池，依此类推。由于 MultiPool 本身从来不会将池标记为故障或不可用，因此对于下一个连接请求，MultiPool 仍会尝试按前述方式提供连接。在 WebLogic Server 版本 8.1 SP3 / 7.0 SP5 及更高版本中，对这一点做了改进，即如果对列表中其中一个池的连接请求失败，便将该池标记为故障。有关详细信息，请查阅增强功能。 如果数据库关闭，MultiPool 配置中的 JDBC 连接池会出现什么情况？ 从池得到连接时，MultiPool 将通过连接测试来检测数据库是否有故障。换言之，MultiPool 并不能检测到 JDBC 连接池的数据库是否有故障，而是通过某个 getConnection() 调用尝试测试和（在必要时）刷新连接，如果失败，将从列表中的下一个池中提供连接。在 WebLogic Server 版本 8.1 SP3 / 7.0 SP5 及更高版本中，对这一点做了改进，即如果对列表中其中一个池的连接请求失败，将暂时禁用该池，并按固定时间间隔执行检查，了解数据库是否恢复了使用。有关详细信息，请查阅增强功能。  如何禁用第一个（或任何）JDBC 连接池以使 Multipool 直接转到列表中的下一个池？ 可以通过控制台暂时禁用 JDBC 连接池，以下位置有对该操作的描述：http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115153 (English)；也可以通过对该池执行 weblogic.Admin SUSPEND_POOL 命令暂时禁用 JDBC 连接池，以下位置有对该操作的描述：http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1296729 (English)。对于较早版本的 WebLogic Server，通过 weblogic.Admin 暂时禁用池的命令是 DISABLE_POOL。 如何在底层数据库恢复正常后恢复使用（MultiPool 中的）JDBC 连接池？ 可以类似方式通过控制台重新启用 JDBC 连接池，以下位置有对该操作的描述：http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1115166 (English)；也可以通过执行 weblogic.Admin RESUME_POOL 命令重新启用 JDBC 连接池，以下位置有对该操作的描述：http://e-docs.bea.com/wls/docs81/admin_ref/cli.html#1300251 (English)。在较早的 WLS 版本 6.1 和 7.0 中，该命令的名称是 ENABLE_POOL。  如何启用因底层数据库故障而被禁用的 JDBC 连接池？ 请在上文中查阅对此问题的解答。 通过拔出网络电缆测试 Failover 情况时，向第二个池的 Failover 为何会花费如此长的时间？ WebLogic Server MultiPool 依赖对数据库连接进行测试和刷新（重建）来确定何时 Failover 到列表中的下一个池。这意味着它要依赖底层 JDBC 驱动程序和网络才能从连接测试和创建即时返回。不过，几乎在所有情况下拔出网络电缆都会导致 Failover 的时间非常长，因为套接字可能要过一段时间（最长可达几分钟）后才真正能够将错误状况返回给调用方。 更有效也更现实的 Failover 情况测试方法是干脆关闭数据库或相应的监听器或数据库计算机本身。在上述情况下，Failover 时间要短得多。 还可以通过这种方法检查当拔出网络电缆时，哪种类型的驱动程序（2 类还是 4 类驱动程序）从连接测试返回的速度更快。 返回页首

WebLogic Server 文档中有关 MultiPool 的常见问题解答  问题：应在何时使用 MultiPool？解答：http://e-docs.bea.com/wls/docs81/faq/jdbc.html#498177 (English) 问题：群集中是否支持 MultiPool？解答：http://e-docs.bea.com/wls/docs81/faq/jdbc.html#500584 (English)。 相关阅读材料  如何配置 WebLogic Server MultiPool：http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_multipools.html#1105912 (English)。如何在 WebLogic Server 和 WebLogic Server 群集中配置和部署 JDBC 组件：http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_multipools.html#1105912 (English)。 Oracle RAC (Real Application Clusters) 配置和测试模式 中提供了有关 Oracle RAC 的附加信息。

已知问题 您可以定期查看所用 WLS 版本的“Release Notes”，了解 Service Pack 中的“Known Issues”或“Resolved Issues”的详细信息及浏览与 JDBC MultiPool 有关的问题。方便起见，下面提供了这些发行说明的链接： WLS 8.1 Release Notes (English) WLS 7.0 Release Notes (English) WLS 6.1 Release Notes (English) 对于需要特别注意之处，请参阅以下 CR，在相应版本 Service Pack 的发行说明中注明了已有针对它们的解决方法： CR174575 / CR175701 - JDBC Multipool 因数组下标增量方式不安全所致的重负载而失败，并抛出 IndexOutOfBoundsException。为解决此问题，已在 WLS 8.1 SP3 (English) 中做了改动。 CR182879 - 当 MultiPool 和 ConnectionPool 同名且 DataSource/TxDataSource 以该名称为目标时，WebLogic Server 在启动过程中未抛出错误。为解决此问题，已在 WLS 8.1 SP4 中做了改动。   使用搜索功能也可以搜索到“Release Notes”，还可以搜索到其它支持解决办法及与 CR 有关的信息，如需要更多帮助？中所提到的内容。如果客户签订了技术支持合同，则可以登录 http://support.bea.com/，登录后会看到为 Solutions 和 Bug Central 提供的 Browse portlet，可在其中按产品版本浏览最新提供的 CR。