Database 恶意进程在Oracle数据库中填充连接

上周我们更新了我们的数据库密码，自从每次数据库反弹后，连接都被填满了。 我们有20多个模式，只有一个模式的连接被填满。会话中没有显示任何内容。可能有旧应用程序使用旧密码访问我们的数据库并填充连接

如何确定有多少进程正在尝试连接到DB服务器，以及有多少进程失败

---

每次我们恢复数据库服务器连接时，经过1小时后，没有其他人可以建立新连接。

顺便说一句：在我们公司，我们有登录和注销触发器，用于保存会话连接和断开连接信息

很可能您看到的是Oracle在需要解析SQL语句时创建的递归会话[通常不是性能问题，但流程参数可能需要增加]：

例如，1，动态_采样的高值会导致生成更多递归SQL

示例2：我已经看到了这种应用程序过度硬解析的情况；这将增加进程数，因为硬解析将需要新进程来执行与解析相关的递归SQL（在本例中，由于它是供应商应用程序，因此增加了processs参数）。由于您的问题与反弹有关，可能是应用程序启动需要大量解析

例3： “会话泄漏”根本原因分析： 问题摘要：我们观察了创建多个会话的时间段，但不清楚应用程序的哪个部分正在创建会话以及创建会话的原因。
RCA方法：由于DB不会保持非活动会话，所以我通过手动快照v$会话来监视这种情况。 分析：
 我注意到一种模式，即多个会话具有相同的过程。  根据Oracle文档，这些会话是Oracle在原始进程下创建的递归会话，该进程需要执行递归SQL以满足查询（在解析级别）。当创建它们的过程完成并退出时，它们就会消失。  如果进程长时间运行，那么它们将一直处于非活动状态，直到完成为止。  这些递归会话不计入会话限制，非活动会话处于空闲等待事件中，不消耗资源。  递归会话无疑是优化器所需的递归SQL的结果，优化器统计数据丢失（如GTT的情况）以及优化器动态采样的初始化参数设置为4。  前几天我们看到的一个小时内的50000个会话可能是运行了几千条select语句的结果（我个人计算过每个查询有20个递归会话，但这个数字可能会有所不同）。
 ADDM报告显示，影响不大： 发现4：会话连接和断开连接 影响为.3[平均]活动会话，占[当前实例上]总活动的6.27%。

---

平均活动会话是数据库负载的度量（接近CPU计数的值将被视为高）。您的实例最多可以处理32个活动会话，因此影响约为容量的1/100。

我们这里讨论的是什么类型的连接？献身的连接池？