实战集锦_WebLogic_JDBC_故障处理总结.pdf

《实战集锦_WebLogic_JDBC_故障处理总结.pdf》由会员分享，可在线阅读，更多相关《实战集锦_WebLogic_JDBC_故障处理总结.pdf（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、实战集锦实战集锦_WebLogic JDBC 故障处理总结故障处理总结 問題描述問題描述 設定 JDBC 連結池或使用不推薦的程式設計技術可引發許多與 JDBC 池連結、相關資料庫或 WebLogic Server 事例有關的各類問題。此外，底層資料庫與網路設定和體系結構也可能導致 JDBC 連結問題。故障排除故障排除 本模式提供了針對其中若干主題的故障排除技巧以及如何進一步探查 JDBC 故障的資訊。請注意，並非下面所有工作都需要完成。有些問題僅通過執行幾項工作就可以解決。快速鏈結（及簡短摘要）：快速鏈結（及簡短摘要）：JDBC 連結池問題 設定和調整 JDBC 連結池是一項非常重要的管理工

2、作，其目的是確保應用程式伺服器及應用程式本身的效能和 穩定性。連結池設定不當可導致許多不同的故障：執行 JDBCDataSource.getConnection()流程中出現 ResourceException(mon.ResourceException:No resources available)RDBMS 或網路效能不佳，向底層資料庫發出的連結請求導致 WebLogic Server 啟動時間漫長由於JDBC 驅動程式設定故障，在建立 JDBC 池連結流程中出現錯誤或例外 資料庫關閉後出現連結更新/重新連結故障 資料庫問題 JDBC 池連結代表底層資料庫中的資料庫會話。JDBC 池設定可

3、導致資料庫本身出現故障。WebLogic Server 和資料庫系統間的網路連結也可引發故障：Oracle 資料庫中打開的游標過多 防火牆會關閉資料庫與 WebLogic Server 間的空閒連結 如果使用 getVendorConnection()來獲得底層物理連結，則應選上屬性 RemoveInfectedConnectionsEnabled 的設定 WebLogic Server 問題 JDBC 池使用 WebLogic Server 資源來執行它們的工作。需對這種情況加以考慮，因為 JDBC 問題可能導致 WebLogic Server 出現以下故障：WebLogic Server

4、因本機 JDBC 驅動程式庫的原因而崩潰 Webogic Server 或應用程式因 JDBC 驅動程式方法或函數而暫停 JDBC 物件記憶體洩漏導致 OutOfMemoryError 或行程大小不斷增加 一般主題 本小節提供以下一般 JDBC 連結池主題的調整和故障排除資訊：通過除錯或追蹤 JDBC 來排除 JDBC 故障 理解 WebLogic Server MultiPool Failover 或負載平衡 如何針對生產環境調整 JDBC 連結池？WebLogic Server 和 Oracle RAC/TAF Oracle ORA-01591 例外 相關閱讀材料 JDBC 連結池問題連結

5、池問題 執行執行 JDBCDataSource.getConnection()流程中出現流程中出現 ResourceException(mon.ResourceException:No resources available)通過 DataSource 向 JDBC 連結池發出的 getConnection()請求未得到滿足時，系統就會拋出 ResourceException。請求未得到滿足的原因不外乎以下兩種：池中沒有連結或沒有可以使用的執行緒來處理連結請求。缺少資源的原因不外乎以下兩種：應用程式中存在連結洩漏應用程式中存在連結洩漏。如果應用程式碼使用的是 JDBC 池中的連結，需要在其使用

6、完畢後將連結關閉。如果未呼叫 close()，連結就得不到釋放，也就無法重複使用連結。Oracle JDBC 連結池連結洩漏的一個可能故障症狀為：顯示 ORA-00020-maximum number of processes(600)exceeded 錯誤資訊。將會單獨設立一個模式來討論此主題，推出該模式時，即會提供更多、更詳細的資訊。WebLogic Server 提供了一種洩漏偵測功能。如果您懷疑應用程式未正確關閉所有 JDBC 池連結，啟用該功能有助於對實際情況進行分析。可以連結池為單位設定該屬性。可登入以下網址來查閱有關 ConnLeakProfilingEnabled 屬性的文件：

7、http:/e- JDBC 池中的資料庫連結數(MaxCapacity)設定為與執行執行緒數相等。該值會限制可同時處於活動狀態（在交易中登記）的資料庫連結的數量，因此進行容量規劃時需要考慮這一因素。儘管應用程式發生了表明池中沒有可用連結的 ResourceException，但同時仍然出現了連結高峰（建立了大量連結）。如果對應用程式的分析表明，保留的連結數比應用程式碼實際使用的連結數要多，並排除了連結洩漏的可能，則最可能的情況是：代表間隔的屬性 RefreshMinutes 的值設定得過小。關閉更新功能：在 WLS 8.1 及以上版本中，將 TestFrequencySeconds 設定為 0

8、；在 WLS 7.0 中，將 RefreshMinutes 設定為 0；在更早的版本中，將 RefreshMinutes 設定為 99999999（此項的最大值為 35791394）。如果設定為 0，將自動恢復到預設值 5 分鐘。背景資訊背景資訊 更新功能專用於使用測試表來測試池中所有當前未使用的連結，並在需要（測試失敗）時更新連結。如果定義了測試表，並在 JDBCConnectionPool 中定義了屬性 RefreshMinutes，便可啟用該功能。在運行上，更新功能與任何用戶端應用程式碼非同步，並會暫時保留所有當前未使用的池連結供測試之用。在整個測試期間，它會一直保留所有這些連結。如果在

9、此期間有新的應用程式連結請求到來，將出現下列情況：如果 InitialCapacity 小於 MaxCapacity，並小於當前打開的 MaxCapacity 連結數，則到來的每個連結請求將打開 CapacityIncrement 個新連結，直至達到池中最多允許的連結數。（這可能導致連結高峰效應，因為打開的連結數可能比實際同時使用的連結數要多。）如果打開的連結數已達最多允許的連結數，就會拋出 ResourceException。應該仔細考慮您的 JDBC 池是否確實需要更新功能。在 WebLogic Server 和資料庫間設有防火牆這種情況下，由於防火牆在實際運行中會關閉空閒的套接字連結，因

10、此非常適合使用更新功能。測試和更新連結的替代方案（如果需要）有：將屬性 TestConnectionsOnReserve 設定為 true。這樣可確保先對從池請求的每個連結進行測試，然後再將它們轉寄給應用程式碼。如果測試失敗，將自動重新打開連結。如果資料庫暫時不可用或停用，可使用 weblogic.Admin RESET_POOL 對連結池進行完整更新。這樣可確保所有連結都得到更新，而更新功能只會更新未使用的連結。RDBMS 或網路效能不佳，向底層資料庫發出的連結請求導致或網路效能不佳，向底層資料庫發出的連結請求導致 WebLogic Server 啟動時間漫長啟動時間漫長 在 WebLogi

11、c Server 啟動流程中，JDBCConnectionPool 中的屬性 InitialCapacity 用於定義將立即建立的連結的數量。如果建立和初始化與資料庫的底層物理連結很耗時，則啟動 WebLogic Server 事例的時間同樣會很漫長。如果向資料庫發出連結請求通常很耗時，而您又不希望 WebLogic Server 啟動時用去如此長的時間，則可以採用替代方案，即將 InitialCapacity 設定為 0。這樣設定後，所建立的池在啟動時將沒有物理連結。如果要在第一個連結請求流程中建立所有連結，請將 CapacityIncrement 設定為池中可用連結的總數。第一個請求將很耗

12、時，但之後連結池將處於完全可用狀態。某些 JDBC 驅動程式（如 WLS 8.1 SP2 及以上版本附帶的 4 類 Oracle 驅動程式）的一些屬性會限制連結請求的最長等待時間。對於這類驅動程式，請在 config.xml 中 JDBCConnectionPool 的 Properties 屬性部分指定 LoginTimeout 屬性。此值將由 WebLogic Server 傳遞給 JDBC 驅動程式。有關詳細資訊，請參閱 S-06615(English)支援解決辦法。因因 JDBC 驅動程式設定問題而在驅動程式設定問題而在 JDBC 池連結建立流程中出現錯誤或例外池連結建立流程中出現錯誤

13、或例外 如前所述，WebLogic Server 將嘗試在啟動時建立 InitialCapacity 個物理連結。如果未正確設定 JDBC 池或在 WebLogic Server 啟動流程中資料庫不可用，物理連結的初始化將不會成功。在 WLS 8.1 之前的版本中，這會導致JDBC 連結池建立不成功，且之後無法使用連結池。對連結池的更新、刪除或重新建立操作也無法進行。針對這一問題的解決方法是，設定一個在啟動時不打開任何連結的 JDBC 池(InitialCapacity=0)。這樣設定後，所建立的連結池將不會有打開的連結，資料庫再次可用後，每個連結請求到達連結池時都將打開 CapacityIn

14、crement 個連結，而如果資料庫仍然停用，則會拋出錯誤資訊。在 WLS 8.1 中，這一行為已發生了變化。如果在 JDBC 池建立流程中發生故障，將建立一個初始連結數為 0 的 JDBC 池。可以在 WebLogic Server 仍處於運行狀態時更改該設定。對池進行了正確設定或資料庫再次可用後，則可建立池連結，並可在應用程式中使用池。有關如何為不同的驅動程式（包括第三方驅動程式）設定 JDBC 連結池的資訊，請登入以下網址：http:/e- JDBC 池設定不正確而產生的典型錯誤資訊如下：如果顯示類似下列資訊的錯誤資訊，請更正所指定的用戶/密碼：Connection Pool myPoo

15、l 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 可能是帳號或密碼無效。也可能是設定中的其他項無效或資料庫不可用。如果顯示類似下列資訊的錯誤資訊，請更正資料庫名稱：如果顯示類似下列資訊的錯誤資訊，請檢查 tns 條目或 PATH、LD_LIBRARY_PATH 等環境設定。在 Windows 系統中，P

16、ATH 需指向用戶端和 OCI 庫，而在 Unix 環境下，LD_LIBRARY_PATH 需指向用戶端安裝複製用戶端和 oci 庫的目錄。#Cannot startup connection pool myPool mon.ResourceException:mon.ResourceException:Could not create pool connection.The DBMS driver exception was:java.sql.SQLException:Io exception:The Network Adapter could not establish the conne

17、ction 如果 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 ER

18、ROR CODE:24327 Cannot startup connection pool xxxPool mon.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 錯誤的更多資訊。語言環境設定不正確可能引發類似下列

19、資訊的錯誤資訊：weblogic.management.DeploymentException:Error creating connection pool myConnectionPool:0:Unable to load locale categories 在啟動 WebLogic Server 前，請確保設定了正確的語言環境。在同一環境中啟動資料庫用戶端來進行復核，並檢查您的語言環境在其中是否有效。資料庫停用後的連結更新資料庫停用後的連結更新/重新連結故障重新連結故障 如果在資料庫處於間歇性停用狀態時將屬性 TestConnectionsOnReserve 設定為 true，且連結測試查

20、詢失敗，就會發生連結重設或更新。您會在 WebLogic Server 日誌檔案中找到類似於下列資訊的相關資訊：ORA-03113 end-of-file on communication channel 和/或 ORA-01012 not logged on：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.exec

21、ute(Statement.java:534)at mon.internal.ConnectionEnv.test(ConnectionEnv.java:961)at mon.internal.ResourceAllocator.reserve(ResourceAllocator.java:651)at mon.internal.ResourceAllocator.reserveUnused(ResourceAllocator.java:575)at mon.internal.ResourceAllocator.trigger(ResourceAllocator.java:1296)at mo

22、n.internal.ScheduledTrigger$1.run(ScheduledTrigger.java:171)at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:807)at mon.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:168)at mon.internal.ScheduledTrigger.execute(ScheduledTrigger.java:158)at weblog

23、ic.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 資料庫中打開的游標數，將拋出下列錯誤資訊：

24、java.sql.SQLException:ORA-01000:maximum open cursors exceeded 這可能是由以下原因造成的：請檢查您在 JDBC 池上有關預處理語句快取的設定。每個預處理語句都將使用 Oracle 資料庫中的一個打開的游標。語句快取以連結為單位儲存預處理語句。這意味著 Oracle 資料庫將為每個設定的池最多使用 (StatementCacheSize)x(MaxCapacity)個打開的游標。由於打開的游標還將用於其他物件（例如，儲存流程或結果集），因此需要將打開游標的數量設定得足夠大，以便能夠在語句快取中儲存所有語句。OPEN_CURSORS 的設

25、定以會話/連結為單位。有關語句快取設定的更多資訊，請參閱：http:/e- 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 publ

26、ic 游標洩漏問題已在 Oracle 9.2.0.5 和 Oracle 10g 中得到解決。Oracle Metalink Case 3151681（須有 Oracle Metalink 登入帳號）對這一已知問題做了說明。有關詳細資訊，請參閱 Investigating ORA-01000:Maximum open cursors exceeded Pattern(English)。防火牆關閉資料庫與防火牆關閉資料庫與 WebLogic Server 間的空閒連結間的空閒連結 如果您在資料庫與 WebLogic Server 間設定了防火牆，而該防火牆在特定時間過後會關閉空閒連結，則可使用 J

27、DBC 池更新功能來確保該防火牆不會關閉池連結。如果使用了防火牆關閉的連結，通常會出現以下錯誤資訊：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 端和資料庫端均認為可以使用該套接字連結，因此兩端均

28、會嘗試寫入該套接字連結，但結果是都遭失敗，因為防火牆已在未向參與方發出通知或錯誤資訊的情況下關閉了該連結。請使用更新功能來確保連結空閒的時間不會長到防火牆會關閉它們的程度。可設定以下屬性來設定更新功能：RefreshMinutes 屬性，設定該屬性可在空閒期間至少對連結進行一次測試。要啟用更新功能，還須設定 TestTableName 屬性。有關詳細資訊，請參閱：http:/e- JDBC 儲存，則每個 JMS 伺服器都會從 JDBC 池獲得一個連結。該連結被視為池的保留連結，因此更新功能不會測試和更新這些連結。典型的錯誤資訊是：JMSServer myJMSServer,store fail

29、ure 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 空閒，

30、則每 5 分鐘對資料庫執行一次 ping，以更新連結，防止防火牆將它們關閉。如果使用如果使用 getVendorConnection()來獲得底層物理連結，則需要檢查屬性來獲得底層物理連結，則需要檢查屬性 RemoveInfectedConnectionsEnabled的設定的設定 某些進階 JDBC 指令要求以物理連結為參數。為此，可以呼叫 getVendorConnection()來獲取連結池所使用的物理連結。不過，為避免後續故障，在實作使用物理連結的應用程式碼時應小心謹慎。由於實作了 JDBC 連結池來確保盡可能高的安全性和可用性，因此對於為其呼叫了 getVendorConnectio

31、n()的任何連結，在應用程式使用後都將被自動更新(RemoveInfectedConnectionsEnabled=true)。由於這意味著連結池化失去了作用，即每個連結在使用後都會被關閉再重新打開，因此請仔細考慮應用 程式碼是否會更改或破壞物理連結上使重新打開成為必要的屬性。在且只有在不存在這種情況時，才能將屬性 RemoveInfectedConnectionsEnabled 設定為 false。有關此屬性的資訊，請參閱：http:/e- Server 問題問題 WebLogic Server 因本機因本機 JDBC 驅動程式庫的原因而崩潰驅動程式庫的原因而崩潰 由於 2 類 JDBC 驅

32、動程式使用本機原始碼，因此這些驅動程式中的故障可能會導致 JVM 和 WebLogic Server 崩潰。如果伺服器崩潰，請查閱二進位核心檔案分析模式中提供的資訊。該資訊將有助於追蹤到導致崩潰的本機庫，並提供了解決該故障的技巧。Webogic Server 或應用程式因或應用程式因 JDBC 驅動程式方法或函數而暫停驅動程式方法或函數而暫停 JDBC 連結使用 WebLogic Server 的執行執行緒來執行它的工作。這意味著一個暫停的資料庫請求會阻塞 WebLogic Server 中的一個執行緒。JDBC 連結或資料庫基礎結構故障可能導致 WebLogic Server 或應用程式暫停

33、。JDBC 導致伺服器暫停模式中提供了有關分析此類故障的資訊。一般伺服器暫停模式中提供了有關如何追蹤到 WebLogic Server 中的暫停故障的一般資訊。JDBC 物件記憶體洩漏導致物件記憶體洩漏導致 OutOfMemoryError 或行程大小不斷增加或行程大小不斷增加 JDBC 連結池中的連結或應用程式碼所使用的 JDBC 物件（直接與資料庫相連）是行程堆或本機記憶體的一部分。如果未能正確關閉或釋放這些物件，就會發生記憶體洩漏，導致堆使用量增加或行程大小不斷增加，最終在 JVM 或作業系統無法再提供可用記憶體時，就會發生 OutOfMemoryError。如果系統發生 OutOfMe

34、moryErrors，並懷疑 JDBC 物件是成因，請查閱 Investigating OutOfMemory/Memory Leak Problems Pattern(English)，瞭解有關如何分析記憶體洩漏故障的資訊。如果在 WebLogic Server 日誌檔案中或通過管理控制臺的 JDBC 池監視功能偵測到連結洩漏錯誤資訊，以下即將推出的模式：探查 JDBC 連結洩漏中提供了排除該故障的方法。推出時將提供相應的鏈結。一般主題一般主題 通過除錯或追蹤通過除錯或追蹤 JDBC 來排除來排除 JDBC 故障故障 要查明故障情況和分析實際傳送到資料庫的 SQL 語句，JDBC 除錯和追蹤

35、功能有時會發揮關鍵作用。不過，JDBC 是一種多層子系統，它只有一部分位於 WebLogic Server 內。JDBC 驅動程式層的除錯和追蹤與驅動程式的類型關係密切。可以從驅動程式供應商處獲得有關驅動程式的除錯和追蹤標誌的資訊。WebLogic Server 端有著不同的 JDBC 除錯標誌：可通過管理控制臺啟用 jDriver JDBC 追蹤，也可以直接在 config.xml 中設定 Server 標誌中的 來啟用該功能。有關詳細資訊，請參閱：http:/e- 中有一些與 JDBC 有關的標誌，可以在 config.xml 中啟用這些標誌。在您要除錯的 WebLogic Server

36、事例中，請於 標誌中插入一個新的 標誌。以下為範例：.此外，也可將這些除錯標誌設定為 WebLogic Server 啟動時的系統屬性：-Dweblogic.Debug=weblogic.JDBCConn,weblogic.JDBCSQL,weblogic.JTAJDBC 這些除錯標誌的除錯和追蹤流程可能會十分冗長，所以請非常仔細地考慮在何處啟用這些標誌。它們會產生大量輸出，可能會對系統性能產生影響。在生產系統中，不應啟用這些標誌。對於不允許啟用 JDBC 除錯功能或列印的資訊不夠多的驅動程式，安裝 P6Spy 驅動程式有助於除錯 JDBC 驅動程式和資料庫間的所有 SQL 語句。這樣可以再實

37、作一個驅動程式層，該層的作用是將除錯資訊輸出到日誌檔案中。可以從以下網站下載該驅動程式：http:/ WebLogic Server MultiPool Failover 或負載平衡或負載平衡 在要求高可用性或負載平衡效能的環境中，可以使用 WebLogic Server MultiPool。MultiPool 行為將隨此設定的不同而變化。請參閱探查 JDBC MultiPool 問題模式，瞭解有關 Multipool Failover 和負載平衡的更多資訊。如何針對生產環境調整如何針對生產環境調整 JDBC 連結池？連結池？針對生產系統設定 JDBC 連結池是確保穩定性和效能的一項關鍵而重要

38、的工作。一些有幫助的一般性的建議可以作為管理員在執行這項工作時的出發點：設定設定 InitialCapacity=MaxCapacity 這樣可以確保 WebLogic Server 啟動時會打開所有連結。由於建立物理資料庫連結的開銷很大，因此應一次打開所有需要的連結，並讓它們保持打開狀態。將將 ShrinkingEnabled 設定為設定為 false 來禁用收縮功能來禁用收縮功能 如前所述，由於建立物理資料庫連結的開銷大，因此應一次性建立所有連結，並讓它們在 WebLogic Server 事例的整個生命週期內保持打開狀態。不需要時可關閉更新功能不需要時可關閉更新功能-有關詳細資訊，請查閱

39、上述的 JDBC 連結池問題和資料庫與 WebLogic Server 之間的防火牆。將 TestConnectionsOnReserve 設定為 true。這樣可以確保先對連結進行測試，然後再將其轉給應用程式，並在需要時重新打開連結。將將 TestConnectionsOnRelease 設定為設定為 false。由於連結測試是應盡可能避免的系統開銷，因此對應用程式返還給池的連結進行連結測試沒有必要。只要在執行 getConnection 流程中對連結進行了測試，就沒有必要再進行測試。將將 JDBC 池中的連結數量設定為與使用這些連結的執行執行緒的數量相等。池中的連結數量設定為與使用這些連結

40、的執行執行緒的數量相等。這有助於避免 ResourceException。WebLogic Server 和和 Oracle RAC/TAF 在為 Oracle RAC/TAF 設定 JDBC 連結池時，有一些細節需要考慮。Oracle RAC(Real Application Clusters)設定和測試模式中提供了這些細節資訊。其中包含有關如何安裝和設定 Oracle RAC 的資訊、有關 Oracle RAC/TAF 常見問題的一些背景資訊、基本除錯技巧以及指向外部資源的鏈結。Oracle ORA-01591 資料庫或參與分散式交易的其他資源的故障可能導致 Oracle 資料庫中出現 O

41、RA-01591 錯誤資訊。以下即將推出的模式：探查 ORA-01591 錯誤資訊將提供有關分析這一問題的資訊。推出時將提供相應的鏈結。相關閱讀材料相關閱讀材料 以下網址中提供了對不同 JDBC 驅動程式及其設定的說明：http:/e- XA 和分散式交易的情況下。有關排除交易相關故障的資訊，請參閱 Investigating Transaction Problems Pattern(English)。http:/e- JDBC 程式設計文件提供了不同類型的 JDBC 驅動程式、它們的包裝器以及如何在應用程式碼中使用它們的相關資訊。該鏈結下還提供了效能調整技巧。有關可用的 JDBCConnec

42、tionPool 屬性的完整清單，請參閱：http:/e- 您可以定期檢視所用 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)使用搜尋功能也可以搜尋到“Release Notes”，還可以搜尋到其他支援解決辦法及與 CR 有關的資訊，如需要更多幫助？中所提到的內容。如果客戶簽訂了技術支援合同，則可以登入 http:/ Solutions 和 Bug Central 提供的 Browse portlet，可在其中按產品版本流覽最新提供的 CR。