探查 JDBC 故障(一)

探查 JDBC 故障(一)


问题描述
 配置 JDBC 连接池或使用不推荐的编程技术可引发许多与 JDBC 池连接、相关数据库或 WebLogic Server 实例有关的各类问题。此外，底层数据库与网络配置和体系结构也可能导致 JDBC 连接问题。 


故障排除
 本模式提供了针对其中若干主题的故障排除技巧以及如何进一步探查 JDBC 故障的信息。请注意，并非下面所有任务都需要完成。有些问题仅通过执行几项任务就可以解决。




JDBC 连接池问题 
 配置和调整 JDBC 连接池是一项非常重要的管理任务，其目的是确保应用程序服务器及应用程序本身的性能和稳定性。连接池配置不当可导致许多不同的故障：
 执行 JDBCDataSource.getConnection() 过程中出现 ResourceException (weblogic.common.ResourceException:No resources available) 
 RDBMS 或网络性能不佳，向底层数据库发出的连接请求导致 WebLogic Server 启动时间漫长 
 由于 JDBC 驱动程序配置故障，在创建 JDBC 池连接过程中出现错误或异常 
 数据库关闭后出现连接刷新/重新连接故障 
 数据库问题 
JDBC 池连接代表底层数据库中的数据库会话。JDBC 池配置可导致数据库本身出现故障。WebLogic Server 和数据库系统间的网络连接也可引发故障：
Oracle 数据库中打开的游标过多 
 防火墙会关闭数据库与 WebLogic Server 间的空闲连接 
 如果使用 getVendorConnection() 来获得底层物理连接，则应选上属性 RemoveInfectedConnectionsEnabled 的设置 
WebLogic Server 问题 
JDBC 池使用 WebLogic Server 资源来执行它们的任务。需对这种情况加以考虑，因为 JDBC 问题可能导致 WebLogic Server 出现以下故障：
WebLogic Server 因本地 JDBC 驱动程序库的原因而崩溃 
Webogic Server 或应用程序因 JDBC 驱动程序方法或函数而挂起 
JDBC 对象内存泄漏导致 OutOfMemoryError 或进程大小不断增加 
 一般主题 
 本小节提供以下一般 JDBC 连接池主题的调整和故障排除信息：
 通过调试或跟踪 JDBC 来排除 JDBC 故障 
 理解 WebLogic Server MultiPool Failover 或负载平衡 
 如何针对生产环境调整 JDBC 连接池？ 
WebLogic Server 和 Oracle RAC/TAF 
 Oracle ORA-01591 异常 
JDBC 连接池问题
 执行 JDBCDataSource.getConnection() 过程中出现 ResourceException (weblogic.common.ResourceException:No resources available)
通过 DataSource 向 JDBC 连接池发出的 getConnection() 请求未得到满足时，系统就会抛出 ResourceException。请求未得到满足的原因不外乎以下两种：池中没有连接或没有可以使用的线程来处理连接请求。缺少资源的原因不外乎以下两种：


应用程序中存在连接泄漏。 
 如果应用程序代码使用的是 JDBC 池中的连接，需要在其使用完毕后将连接关闭。如果未调用 close()，连接就得不到释放，也就无法重复使用连接。Oracle JDBC 连接池连接泄漏的一个可能故障症状为：显示
ORA-00020 - maximum number of processes (600) exceeded 错误信息。
 将会单独设立一个模式来讨论此主题，推出该模式时，即会提供更多、更详细的信息。




WebLogic Server 提供了一种泄漏检测功能。如果您怀疑应用程序未正确关闭所有 JDBC 池连接，启用该功能有助于对实际情况进行分析。可以连接池为单位设置该属性。可登录以下网址来查阅有关 ConnLeakProfilingEnabled 属性的文档： 


(English)。可以通过控制台设置此属性。与此相关的信息，请参阅： (English)。 


配置的线程数过少或配置的连接数 (MaxCapacity) 过少，无法建立应用程序所需的足够数量的并发活动数据库连接。
 对于这种情况，一般的经验方法是将 JDBC 池中的数据库连接数 (MaxCapacity) 配置为与执行线程数相等。该值会限制可同时处于活动状态（在事务中登记）的数据库连接的数量，因此进行容量规划时需要考虑这一因素。 
 尽管应用程序发生了表明池中没有可用连接的 ResourceException，但同时仍然出现了连接高峰（创建了大量连接）。 
 如果对应用程序的分析表明，保留的连接数比应用程序代码实际使用的连接数要多，并排除了连接泄漏的可能，则最可能的情况是：代表间隔的属性 RefreshMinutes 的值设置得过小。关闭刷新功能：


在 WLS 8.1 及以上版本中，将 TestFrequencySeconds 设置为 0； 
 在 WLS 7.0 中，将 RefreshMinutes 设置为 0； 
 在更早的版本中，将 RefreshMinutes 设置为 99999999（此项的最大值为 35791394）。如果设置为 0，将自动恢复到缺省值 5 分钟。 
 背景信息 
 刷新功能专用于使用测试表来测试池中所有当前未使用的连接，并在需要（测试失败）时刷新连接。如果定义了测试表，并在 JDBCConnectionPool 中定义了属性 RefreshMinutes，便可启用该功能。


在运行上，刷新功能与任何客户端应用程序代码异步，并会暂时保留所有当前未使用的池连接供测试之用。在整个测试期间，它会一直保留所有这些连接。如果在此期间有新的应用程序连接请求到来，将出现下列情况： 
 如果 InitialCapacity 小于 MaxCapacity，并小于当前打开的 MaxCapacity 连接数，则到来的每个连接请求将打开 CapacityIncrement 个新连接，直至达到池中最多允许的连接数。（这可能导致连接高峰效应，因为打开的连接数可能比实际同时使用的连接数要多。） 
 如果打开的连接数已达最多允许的连接数，就会抛出 ResourceException。 
 应该仔细考虑您的 JDBC 池是否确实需要刷新功能。在 WebLogic Server 和数据库间设有防火墙这种情况下，由于防火墙在实际运行中会关闭空闲的套接字连接，因此非常适合使用刷新功能。（有关这方面的详细信息，请参阅防火墙关闭空闲连接。）


测试和刷新连接的替代方案（如果需要）有：


将属性 TestConnectionsOnReserve 设置为 true。这样可确保先对从池请求的每个连接进行测试，然后再将它们转发给应用程序代码。如果测试失败，将自动重新打开连接。 
 如果数据库暂时不可用或停用，可使用 weblogic.Admin RESET_POOL 对连接池进行完整刷新。这样可确保所有连接都得到刷新，而刷新功能只会刷新未使用的连接。 


RDBMS 或网络性能不佳，向底层数据库发出的连接请求导致 WebLogic Server 启动时间漫长
 在 WebLogic Server 启动过程中，JDBCConnectionPool 中的属性 InitialCapacity 用于定义将立即创建的连接的数量。如果创建和初始化与数据库的底层物理连接很耗时，则启动 WebLogic Server 实例的时间同样会很漫长。


如果向数据库发出连接请求通常很耗时，而您又不希望 WebLogic Server 启动时用去如此长的时间，则可以采用替代方案，即将 InitialCapacity 设置为 0。这样设置后，所创建的池在启动时将没有物理连接。如果要在第一个连接请求过程中创建所有连接，请将 CapacityIncrement 设置为池中可用连接的总数。第一个请求将很耗时，但之后连接池将处于完全可用状态。


某些 JDBC 驱动程序（如 WLS 8.1 SP2 及以上版本附带的 4 类 Oracle 驱动程序）的一些属性会限制连接请求的最长等待时间。对于这类驱动程序，请在 config.xml 中 JDBCConnectionPool 的 Properties 属性部分指定 LoginTimeout 属性。此值将由 WebLogic Server 传递给 JDBC 驱动程序。有关详细信息，请参阅 S-06615 (English) 支持解决办法。