1,237
社区成员
发帖
与我相关
我的任务
分享Patch 8174835、 Patch 8188896补丁的下载和使用
该问题属于Weblogic 在该版本已知bug，官方文档
java.sql.SQLException: Connection has been administratively disabled. Try later. (文档 ID 1211143.1) 对问题进行了详细的描述
问题版本与症状：
引起的原因：
引起该问题有两种原因：
（1）数据库不可用导致
（2）Weblogic bug导致
针对cause1，建议数据库工程师检查数据库，是否存在较为严重问题导致数据库中间件连接中断。
针对Cause2、Cause3建议为该版本Weblogic打Patch 8174835、 Patch 8188896补丁。请问各位大神，这两个补丁再哪里下载，使用的时候有没有先后顺序？谢谢大神们~
...全文
请发表友善的回复…
发表回复
fengyq17290 2017-11-26
- 打赏
- 举报
楼主这两个补丁弄到了么？可否发我一份270637942@qq.com，谢谢，急用！！！
qq_25366567 2017-08-03
- 打赏
- 举报
In my opinion, these two patches are about the problem "java.sql.SQLException: Connection has been administ administially supported. Try later." However, fundamentally speaking, your problem does not come from this. If you really sure your problem is derived from the database, then I suggest you can go to the official website to download the latest version of the database, or upgrade your database for the latest version.
Official website: https: //www.oracle.com/search/results? Cat = otn & Ntk = S3 & Ntt = patch
Of course, there are some patches for bug fixes in this URL.
Hope my advice is useful to you!
qq_25366567 2017-08-03
- 打赏
- 举报
There are three possible causes for this SQLException:
Cause 1. If your DBMS becomes and remains unavailable, the data source will test and try to replace dead connections while trying to satisfy connection requests. This behavior is beneficial because it enables the data source to react immediately when the database becomes available. However, testing a dead database connection can take as long as the network timeout, and can cause a long delay for clients.
To minimize this delay, the WLS data sources include logic that disables the data source after 2 consecutive failures to replace a dead connection. When an application requests a connection from a disabled data source, WebLogic Server throws a PoolDisabledSQLException immediately to notify the client that a connection is not available.
Cause 2. There is a known issue addressed by unpublished defect 8174835. When an application retrieves a connection from the JDBC pool, the implementation will check if it thinks that the connections are hanging. The check is based on pending tests that takes more time than is 'typical.' And typical means the max time for the last 10 successful tests. The problem is that a test can either be a local java call that returns immediately or it can query the database. So the worst case is when a system has a burst of connection requests, but the last 10 successful tests are local calls that we can assume takes less than 1 ms. In this case we wait about 20 ms (a loop of 20 iterations is performed) before we assume that the connection is hanging. And at high loads it is not uncommon that the DB query takes more than that time.
Cause 3. There is another known issue addressed by Bug 8188896. The JVM will occasionally, for a brief period during GC, halt all threads, including our connection tests, which may have been taking 1-2 milliseconds consistently for hours, but for this brief period may have to wait multiple seconds before getting their successful response. Our pool code, which is designed to protect against DBMS partition and network hangs that can last for minutes, was relying on tests to always take about as long, and they don't, so this code was disabling a pool that would be fine within 5-10 seconds.The new code will allow for a test to take up to 10 seconds maximum now, by default, and this can either be extended, or made essentially unlimited by a command-line option added to the line that starts java for the server:
