我们有一个针对 Oracle 11g 数据库在 Weblogic 上运行的 JavaEE 应用程序，使用瘦 JDBC 驱动程序。 最近我们在生产中发生了一系列事件，更新和插入某个表时卡住或花费的时间比正常情况长得多，没有明显的原因。 这导致应用程序使用越来越多的数据库连接(通常在连接池中空闲)，数据库 CPU 和并发性激增(如在 OEM 中所见)，整个数据库陷入停顿。 在这些事件中，DBA 找不到插入和更新卡住的任何原因(没有数据库锁)。他们确实看到了很多“来自客户端的 SQL*Net 等待消息”事件。
他们的理论是，应用程序(jdbc 客户端)在插入/更新语句期间由于与数据库无关的原因以某种方式卡住了，同时没有确认数据库对这些语句的响应。事实上，应用程序继续发出越来越多的此类语句，占用越来越多的连接，这就是 CPU 和并发性飙升，导致数据库无响应的原因。
我不相信 - 如果所有 session 都忙于等待客户端，CPU 怎么会这么高？ 我们无法始终如一地重现这些事件，所以我们真的一无所知...
有没有人见过这样的事情或者有任何想法，这可能是由什么引起的？
谢谢
最佳答案
您所描述的是“连接 Storm ”。配置不当的连接池将通过打开新连接来为等待请求提供服务来“处理”响应缓慢的连接。这些额外的请求给已经承受压力的服务器带来了进一步的压力(如果没有压力，初始连接就不会滞后)。这会启动一个不良响应循环，产生额外的连接，最终杀死服务器。
您可以通过将数据源的最大容量设置为合理的值来避免连接 Storm 。 “合理”的定义会根据您的服务器的能力而有所不同，但它可能比您想象的要低。最好的建议是将最大容量设置为与初始容量相同的值。
一旦阻止了连接 Storm ，您就可以专注于导致初始速度变慢的数据库进程。
来自客户端的大量SQL*Net wait message 事件表明客户端正在做一些事情而没有联系数据库。这就是为什么您的 DBA 认为问题出在应用程序上。
关于Oracle 更新/插入卡住，数据库 CPU 占用 100%，并发性高，来自客户端的 SQL*Net 等待消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14043668/