Oracle更新/插入卡住，DB CPU为100%，并发性高，来自客户端的SQL*Net等待消息

我们有一个在Weblogic上运行的JavaEE应用程序，它使用瘦JDBC驱动程序，针对Oracle 11g DB。 最近，我们在生产中发生了一系列事件，在没有明显原因的情况下，某个表中的更新和插入被卡住或花费了比正常情况更长的时间。 这导致应用程序使用越来越多的数据库连接（连接池中通常处于空闲状态），数据库CPU和并发性急剧上升（如OEM中所示），整个数据库停止运行。 在这些事件中，DBA找不到插入和更新被卡住的任何原因（没有db锁）。他们看到的是大量来自客户端的“SQL*Net等待消息””事件

他们的理论是，应用程序（jdbc客户机）在insert/update语句期间不知何故被卡住了，原因与DB无关，同时没有确认DB对这些语句的响应。事实上，应用程序继续发出越来越多的这些语句，占用越来越多的连接，这是CPU和并发性急剧上升的原因，使数据库没有响应

我不相信——如果所有的会话都在忙着等待客户端，为什么CPU会这么高？ 我们无法始终如一地重现这些事件，所以我们在这里真的很黑暗

有没有人看到过类似的情况，或者有什么想法和建议来解释这可能是由什么引起的

---

谢谢你所描述的是一场“连接风暴”。配置不当的连接池将通过打开新连接以服务等待请求来“处理”响应缓慢的连接。这些额外的请求给已经承受压力的服务器带来了进一步的压力（如果没有压力，初始连接就不会滞后）。这会启动一个响应差的循环，产生额外的连接，最终导致服务器死亡

通过将数据源的最大容量设置为合理的值，可以避免连接风暴。“合理”的定义将根据服务器的功能而有所不同，但可能比您想象的要低。最好的建议是将最大容量设置为与初始容量相同的值

一旦防止了连接风暴，您就可以将注意力集中在导致初始速度减慢的数据库进程上

---

---

来自客户端的大量

SQL*Net wait消息

事件表明客户端正在做一些事情，而没有与数据库联系。这就是为什么您的DBA认为问题出在应用程序上。

我遇到了一个类似的问题，我在这里记录了这个问题：。在我的例子中，问题是由类型为

CLOB

的bind变量引起的，该变量绑定到

CLOB

s似乎会在Oracle中引起严重问题的位置。以下语句产生与您观察到的行为相同的行为：

CREATE TABLE t (
  v INT, 
  s VARCHAR2(400 CHAR)
);

var v_s varchar2(50)
exec :v_s := 'abc'

MERGE INTO t                      
USING (
  SELECT 
    1 v, 
    CAST(:v_s AS CLOB) s 
  FROM DUAL
) s 
ON (t.s = s.s) -- Using a CLOB here causes the bug.
WHEN MATCHED THEN UPDATE SET
  t.v = s.v        
WHEN NOT MATCHED THEN INSERT (v, s) 
VALUES (s.v, s.s);

---

可能，除了

MERGE

之外，还有其他语句公开了这种产生僵尸会话的行为，由于Oracle似乎在运行一些无限循环，从而产生观察到的CPU负载。

可能需要尝试扩展表空间—可能存在磁盘空间问题？Oracle是否与WebLogic在同一台服务器上运行？或者在不同的服务器上？有一百万个原因，非常确切地说。。。正如@randy所做的那样，我会把重点放在操作系统、磁盘/文件系统（您没有使用ZFS/NAS，是吗？）等方面，但我只能胡乱猜测，可能是错的。在这种情况发生时，如果没有根用户访问您的邮箱，我看不出这里的任何人如何能够有意义地帮助您。当这种事情发生时，我通常会找几个系统管理员和一个或两个DBA，确保每个人都坐在一起。。。我们这里没有那种奢侈。你想要什么样的答案？@code:数据库运行在一台专用服务器上。@Ben:你当然是对的，问题是DBA和系统管理员在这种情况发生时（发生了好几次）查看了系统，我们仍然没有一个有意义的答案。。。我想我只是希望有人能提出一些我们没有想到的建议……事实上，我们的连接池配置为在启动时打开所有连接（初始容量=最大容量），因此在负载下它永远不会打开更多的连接。关于SQL*Net等待-我仍然不明白它是如何导致高CPU和数据库无响应的…我遇到了类似的问题，但即使在客户端离开后，仍然会出现连接阻塞。。。