探查 JDBC 故障【转载】

转载自:http://www.blogjava.net/coolplay/articles/226406.html?opt=admin

探查 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 属性的文档：

http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#ConnLeakProfilingEnabled (English)。可以通过控制台设置此属性。与此相关的信息，请参阅：http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_config_connections.html#1104722 (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) 支持解决办法。

探查 JDBC 故障(二)

因 JDBC 驱动程序配置问题而在 JDBC 池连接创建过程中出现错误或异常
如前所述，WebLogic Server 将尝试在启动时创建 InitialCapacity 个物理连接。如果未正确配置 JDBC 池或在 WebLogic Server 启动过程中数据库不可用，物理连接的初始化将不会成功。在 WLS 8.1 之前的版本中，这会导致 JDBC 连接池创建不成功，且之后无法使用连接池。对连接池的刷新、删除或重新创建操作也无法进行。针对这一问题的解决方法是，配置一个在启动时不打开任何连接的 JDBC 池 (InitialCapacity="0")。这样设置后，所创建的连接池将不会有打开的连接，数据库再次可用后，每个连接请求到达连接池时都将打开 CapacityIncrement 个连接，而如果数据库仍然停用，则会抛出错误信息。

在 WLS 8.1 中，这一行为已发生了变化。如果在 JDBC 池创建过程中发生故障，将创建一个初始连接数为 0 的 JDBC 池。可以在 WebLogic Server 仍处于运行状态时更改该配置。对池进行了正确配置或数据库再次可用后，则可创建池连接，并可在应用程序中使用池。


有关如何为不同的驱动程序（包括第三方驱动程序）配置 JDBC 连接池的信息，请登录以下网址：http://e-docs.bea.com/wls/docs81/jdrivers.html (English)。

因 JDBC 池配置不正确而产生的典型错误信息如下：

如果显示类似下列信息的错误信息，请更正所指定的用户/密码：
<05.11.2003 11.38 Uhr CET> <Error> <JDBC> <BEA-001150> <Connection Pool "myPool" deployment failed with the following error: 0:
Could not connect to 'oracle.jdbc.driver.OracleDriver'.

The returned message is: ORA-01017: invalid username/password; logon denied

可能是登录名或密码无效。
也可能是配置中的其它项无效或数据库不可用。
如果显示类似下列信息的错误信息，请更正数据库名称：
<06.11.2003 14.21 Uhr CET> <Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "myPool": E/A-Exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153092352)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=125
05)(EMFI=4))))>
<06.11.2003 14.21 Uhr CET> <Error> <JDBC> <BEA-001150> <Connection Pool "myPool"
deployment failed with the following error:
0:Could not create pool connection. The DBMS driver exception was: E/A-Exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153092352)(ERR=12505)
(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4)))).>

如果显示类似下列信息的错误信息，请检查 tns 条目或 PATH、LD_LIBRARY_PATH 等环境设置。在 Windows 系统中，PATH 需指向客户端和 OCI 库，而在 Unix 环境下，LD_LIBRARY_PATH 需指向客户端安装复制客户端和 oci 库的目录。
####<Apr 17, 2003 1:58:44 PM CEST> <Error> <JDBC> <mydomain> <myserver> <main> <kernel identity> <> <001060> <Cannot startup connection pool "myPool" weblogic.common.ResourceException:
weblogic.common.ResourceException:
Could not create pool connection. The DBMS driver exception was:java.sql.SQLException: Io exception: The Network Adapter could not establish the connection



如果 tnsnames.ora 文件或 ORACLE_HOME 设置得不正确，将抛出以下 Oracle 错误：
ORA-12154: TNS could not resolve service name

请确保 ORACLE_HOME 环境变量所指向的目录正确，且 tnsnames.ora 文件存储在正确的目录中。请通过 sql-plus 验证是否可以成功连接到此数据库。S-08804 (English) 支持解决办法中提供了有关 ORA-12154 和相关 Oracle SQL 错误的更多信息。

与此相关的错误信息为 ORA-24327 - 配置故障引发该错误信息的可能性最大： LOGIN ERROR CODE: 24327
<Error> <JDBC Connection Pool> Cannot startup connection pool "xxxPool" weblogic.common.ResourceException:Could not create pool connection. The DBMS driver exception was: java.sql.SQLException: ORA-24327: need explicit attach before authenticating a user .

S-08804 (English) 支持解决办法中提供了有关 ORA-24327 和相关 Oracle SQL 错误的更多信息。

语言环境设置不正确可能引发类似下列信息的错误信息：
weblogic.management.DeploymentException: Error creating connection pool myConnectionPool: 0:Unable to load locale categories

在启动 WebLogic Server 前，请确保设置了正确的语言环境。在同一环境中启动数据库客户端来进行复核，并检查您的语言环境在其中是否有效。

数据库停用后的连接刷新/重新连接故障
如果在数据库处于间歇性停用状态时将属性 TestConnectionsOnReserve 设置为 true，且连接测试查询失败，就会发生连接重设或刷新。您会在 WebLogic Server 日志文件中找到类似于下列信息的相关信息：

ORA-03113 end-of-file on communication channel 和/或 ORA-01012 not logged on： <Jan 31, 2002 2:20:17 PM PST> <Info> <JDBC Pool oraclePool> <null> <This connection will now be refreshed.>

<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC> <001067> <Connection for pool "oraclePool" refreshed.>

<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC Pool oraclePool> <null> <A connection from pool oraclePool was tested during reserve with a select count(*) from dual and failed:>

<Jan 31, 2002 2:20:18 PM PST> <Info> <JDBC Pool oraclePool> <null>

<java.sql.SQL

Exception: ORA-03113: end-of-file on communication channel

at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:240)

at weblogic.jdbc.oci.Statement.execute(Statement.java:534)

at weblogic.jdbc.common.internal.ConnectionEnv.test(ConnectionEnv.java:961)

at weblogic.jdbc.common.internal.ResourceAllocator.reserve
(ResourceAllocator.java:651)

at weblogic.jdbc.common.internal.ResourceAllocator.reserveUnused
(ResourceAllocator.java:575)

at weblogic.jdbc.common.internal.ResourceAllocator.trigger
(ResourceAllocator.java:1296)

at weblogic.time.common.internal.ScheduledTrigger$1.run(ScheduledTrigger.java:171)

at weblogic.security.service.SecurityServiceManager.runAs
(SecurityServiceManager.java:807)

at weblogic.time.common.internal.ScheduledTrigger.executeLocally
(ScheduledTrigger.java:168)

at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:158)

at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:38)

at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:156)

at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:137)

此信息只是通知信息，只要之后可成功创建连接，您没有必要担心。



数据库问题
Oracle 数据库中打开的游标过多
如果超过了配置的允许在 Oracle 数据库中打开的游标数，将抛出下列错误信息：

java.sql.SQLException: ORA-01000: maximum open cursors exceeded

这可能是由以下原因造成的：

请检查您在 JDBC 池上有关预处理语句缓存的配置。每个预处理语句都将使用 Oracle 数据库中的一个打开的游标。语句缓存以连接为单位存储预处理语句。这意味着 Oracle 数据库将为每个配置的池最多使用
(StatementCacheSize) x(MaxCapacity) 个打开的游标。由于打开的游标还将用于其它对象（例如，存储过程或结果集），因此需要将打开游标的数量配置得足够大，以便能够在语句缓存中存储所有语句。OPEN_CURSORS 的设置以会话/连接为单位。
有关语句缓存配置的更多信息，请参阅：http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#StatementCacheSize (English)
某些版本的 Oracle 驱动程序（thin 或 oci）的 XA 驱动程序类 (oracle.jdbc.xa.client.OracleXADataSource) 中有游标泄漏，该泄漏会导致一段时间后出现 ORA-01000 错误信息。请确保数据库端的 DBA_PENDING_TRANSACTION 视图有相应的权限：
grant DBA_PENDING_TRANSACTIONS to public
grant DBA_PENDING_NEIGHBORS to public
grant DBA_2PC_PENDING to public


游标泄漏问题已在 Oracle 9.2.0.5 和 Oracle 10g 中得到解决。Oracle Metalink Case 3151681（须有 Oracle Metalink 登录帐号）对这一已知问题做了说明。


防火墙关闭数据库与 WebLogic Server 间的空闲连接
如果您在数据库与 WebLogic Server 间配置了防火墙，而该防火墙在特定时间过后会关闭空闲连接，则可使用 JDBC 池刷新功能来确保该防火墙不会关闭池连接。如果使用了防火墙关闭的连接，通常会出现以下错误信息：


java.sql.SQLException: ORA-03113: end-of-file on communication channel
     at weblogic.db.oci.OciCursor.getCDAException(OciCursor.java:240)      at weblogic.jdbc.oci.Statement.executeQuery(Statement.java:916)
     at ...

发生该错误的原因是，WebLogic Server 端和数据库端均认为可以使用该套接字连接，因此两端均会尝试写入该套接字连接，但结果是都遭失败，因为防火墙已在未向参与方发出通知或错误信息的情况下关闭了该连接。请使用刷新功能来确保连接空闲的时间不会长到防火墙会关闭它们的程度。

可设置以下属性来配置刷新功能：

RefreshMinutes 属性，设置该属性可在空闲期间至少对连接进行一次测试。要启用刷新功能，还须设置 TestTableName 属性。有关详细信息，请参阅：http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#RefreshMinutes (English)
不过，如果定义了 JDBC 存储，则每个 JMS 服务器都会从 JDBC 池获得一个连接。该连接被视为池的保留连接，因此刷新功能不会测试和刷新这些连接。典型的错误信息是：

JMSServer "myJMSServer", store failure while writing message for queue myQueue, java.io.IOException

可通过以下两种方法之一更正这一错误：

在空闲期间至少发送一条哑元 JMS 信息，这样防火墙就不会关闭该连接
禁用防火墙关闭连接功能
另外定义一个 JDBC 池，将其用作 JMS 服务器的 JDBC 存储，并在空闲期间使用
weblogic.Admin RESET_POOL 再次打开连接至少一次
在 WebLogic Server 的较高版本（WLS 6.1 SP7、WLS 7.0 SP3 和 WLS 8.1 SP1）中，
该故障已得到解决，解决方法是：如果 JMS 空闲，则每 5 分钟对数据库执行一次 ping，以刷新连接，
防止防火墙将它们关闭。


如果使用 getVendorConnection() 来获得底层物理连接，则需要检查属性RemoveInfectedConnectionsEnabled的设置
某些高级 JDBC 命令要求以物理连接为参数。为此，可以调用 getVendorConnection()
来获取连接池所使用的物理连接。

不过，为避免后续故障，在实现使用物理连接的应用程序代码时应小心谨慎。由于实现了 JDBC
连接池来确保尽可能高的安全性和可用性，因此对于为其调用了 getVendorConnection()的任何连接，
在应用程序使用后都将被自动刷新 (RemoveInfectedConnectionsEnabled="true")。

由于这意味着连接池化失去了作用，即每个连接在使用后都会被关闭再重新打开，因此请仔细考虑应用
程序代码是否会更改或破坏物理连接上使重新打开成为必要的属性。在且只有在不存在这种情况时，
才能将属性 RemoveInfectedConnectionsEnabled设置为 false。

有关此属性的信息，请参阅：
http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html
#RemoveInfectedConnectionsEnabled (English)。



WebLogic Server 问题
WebLogic Server 因本地 JDBC 驱动程序库的原因而崩溃
由于 2 类 JDBC 驱动程序使用本地代码，因此这些驱动程序中的故障可能会导致 JVM 和 WebLogic Server 崩溃。如果服务器崩溃，请查阅二进制核心文件分析模式中提供的信息。该信息将有助于跟踪到导致崩溃的本地库，并提供了解决该故障的技巧。

Webogic Server 或应用程序因 JDBC 驱动程序方法或函数而挂起
JDBC 连接使用 WebLogic Server 的执行线程来执行它的工作。这意味着一个挂起的数据库请求会阻塞 WebLogic Server 中的一个线程。JDBC 连接或数据库基础结构故障可能导致 WebLogic Server 或应用程序挂起。JDBC 导致服务器挂起模式中提供了有关分析此类故障的信息。常规服务器挂起模式中提供了有关如何跟踪到 WebLogic Server 中的挂起故障的一般信息。

JDBC 对象内存泄漏导致 OutOfMemoryError 或进程大小不断增加
JDBC 连接池中的连接或应用程序代码所使用的 JDBC 对象（直接与数据库相连）是进程堆或本地内存的一部分。如果未能正确关闭或释放这些对象，就会发生内存泄漏，导致堆使用量增加或进程大小不断增加，最终在 JVM 或操作系统无法再提供可用内存时，就会发生 OutOfMemoryError。

如果系统发生 OutOfMemoryErrors，并怀疑 JDBC 对象是成因，请查阅 Investigating OutOfMemory/Memory Leak Problems Pattern (English)，了解有关如何分析内存泄漏故障的信息。如果在 WebLogic Server 日志文件中或通过管理控制台的 JDBC 池监视功能检测到连接泄漏错误信息，以下即将推出的模式：探查 JDBC 连接泄漏中提供了排除该故障的方法。推出时将提供相应的链接。
 


探查 JDBC 故障(三)
2008年03月13日 星期四 23:39
一般主题
通过调试或跟踪 JDBC 来排除 JDBC 故障
要查明故障情况和分析实际发送到数据库的 SQL 语句，JDBC 调试和跟踪功能有时会发挥关键作用。不过，JDBC 是一种多层子系统，它只有一部分位于 WebLogic Server 内。JDBC 驱动程序层的调试和跟踪与驱动程序的类型关系密切。可以从驱动程序供应商处获得有关驱动程序的调试和跟踪标志的信息。

WebLogic Server 端有着不同的 JDBC 调试标志：

可通过管理控制台启用 jDriver JDBC 跟踪，也可以直接在 config.xml 中设置 Server 标志中的 <JDBCLoggingEnabled> 来启用该功能。有关详细信息，请参阅：http://e-docs.bea.com/wls/docs81/config_xml/Server.html#JDBCLogFileName (English)。
ServerDebugMBean 中有一些与 JDBC 有关的标志，可以在 config.xml 中启用这些标志。在您要调试的 WebLogic Server 实例中，请于 <Server> 标志中插入一个新的 <ServerDebug> 标志。以下为示例：
<Server Name="myserver" >
....
    <ServerDebug Name="myserver" JDBCConn="true" JDBCSQL="true" JTAJDBC="true" />
</Server>
此外，也可将这些调试标志设置为 WebLogic Server 启动时的系统属性：
-Dweblogic.Debug=weblogic.JDBCConn,weblogic.JDBCSQL,weblogic.JTAJDBC

这些调试标志的调试和跟踪过程可能会十分冗长，所以请非常仔细地考虑在何处启用这些标志。它们会产生大量输出，可能会对系统性能产生影响。在生产系统中，不应启用这些标志。

对于不允许启用 JDBC 调试功能或打印的信息不够多的驱动程序，安装 P6Spy 驱动程序有助于调试 JDBC 驱动程序和数据库间的所有 SQL 语句。这样可以再实现一个驱动程序层，该层的作用是将调试信息输出到日志文件中。可以从以下网站下载该驱动程序：

http://www.p6spy.com/
以下网址提供了文档和安装说明：http://www.p6spy.com/documentation/index.htm。



理解 WebLogic Server MultiPool Failover 或负载平衡
在要求高可用性或负载平衡性能的环境中，可以使用 WebLogic Server MultiPool。MultiPool 行为将随此配置的不同而变化。请参阅探查 JDBC MultiPool 问题模式，了解有关 Multipool Failover 和负载平衡的更多信息。

如何针对生产环境调整 JDBC 连接池？
针对生产系统配置 JDBC 连接池是确保稳定性和性能的一项关键而重要的任务。一些有帮助的一般性的建议可以作为管理员在执行这项任务时的出发点：

设置 InitialCapacity = MaxCapacity
这样可以确保 WebLogic Server 启动时会打开所有连接。由于创建物理数据库连接的开销很大，因此应一次打开所有需要的连接，并让它们保持打开状态。
将 ShrinkingEnabled 设置为 false 来禁用收缩功能
如前所述，由于创建物理数据库连接的开销大，因此应一次性建立所有连接，并让它们在 WebLogic Server 实例的整个生命周期内保持打开状态。
不需要时可关闭刷新功能 - 有关详细信息，请查阅上述的 JDBC 连接池问题和数据库与 WebLogic Server 之间的防火墙。
将 TestConnectionsOnReserve 设置为 true。
这样可以确保先对连接进行测试，然后再将其转给应用程序，并在需要时重新打开连接。
将 TestConnectionsOnRelease 设置为 false。
由于连接测试是应尽可能避免的系统开销，因此对应用程序返还给池的连接进行连接测试没有必要。只要在执行 getConnection 过程中对连接进行了测试，就没有必要再进行测试。
将 JDBC 池中的连接数量设置为与使用这些连接的执行线程的数量相等。
这有助于避免 ResourceException。


WebLogic Server 和 Oracle RAC/TAF
在为 Oracle RAC/TAF 配置 JDBC 连接池时，有一些细节需要考虑。Oracle RAC (Real Application Clusters) 配置和测试模式中提供了这些细节信息。其中包含有关如何安装和配置 Oracle RAC 的信息、有关 Oracle RAC/TAF 常见问题的一些背景信息、基本调试技巧以及指向外部资源的链接。

Oracle ORA-01591
数据库或参与分布式事务的其它资源的故障可能导致 Oracle 数据库中出现 ORA-01591 错误信息。以下即将推出的模式：探查 ORA-01591 错误信息将提供有关分析这一问题的信息。推出时将提供相应的链接。


相关阅读材料
以下网址中提供了对不同 JDBC 驱动程序及其配置的说明：http://e-docs.bea.com/wls/docs81/jdrivers.html (English)。还请检查数据库特有设置，尤其是在使用 XA 和分布式事务的情况下。

有关排除事务相关故障的信息，请参阅 Investigating Transaction Problems Pattern (English)。

http://e-docs.bea.com/wls/docs81/jdbc/index.html (English) 上的 JDBC 编程文档提供了不同类型的 JDBC 驱动程序、它们的包装器以及如何在应用程序代码中使用它们的相关信息。该链接下还提供了性能调整技巧。

有关可用的 JDBCConnectionPool 属性的完整列表，请参阅：http://e-docs.bea.com/wls/docs81/config_xml/JDBCConnectionPool.html#252800 (English)。