上周我们更新了我们的数据库密码，自从每次数据库反弹后，连接都被填满了。 我们有20多个架构和连接，只有一个架构被填满。会议中没有任何内容。可能有旧应用程序使用旧密码访问我们的数据库并填写连接。
如何识别尝试连接到数据库服务器的进程数以及失败的进程数。
每次我们退回我们的数据库服务器连接都要经过1小时后，其他任何人都无法建立新连接。
答案 0 :(得分：0)
很有可能你看到的是Oracle在需要解析SQL语句时创建的递归会话[通常不是性能问题，但可能需要增加进程参数]：...
例如1，dynamic_sampling的高值会导致生成更多的递归SQL;
示例2：我已经看到过度硬解析的应用情况;这将推动进程数，因为硬解析将需要新进程来执行与解析相关的递归SQL（在这种情况下增加了进程参数，因为它是供应商应用程序）。由于您的问题与退回有关，因此可能是应用启动需要大量解析。
示例3：
“会话泄漏”根本原因分析：
问题摘要：我们观察了创建许多会话的时间段，但没有清楚地了解应用程序的哪个部分正在创建它们以及为什么
RCA方法：由于数据库不会保持非活动会话，因此我通过手动快照v $ session来监控情况。
分析：
我注意到一个模式，其中多个会话具有相同的进程＃。
根据Oracle文档，这些会话是由oracle在原始进程下创建的递归会话，需要执行递归SQL以满足查询（在解析级别）。当创建它们的过程完成并退出时，它们就会消失。
如果进程长时间运行，那么它们将保持非活动状态，直到完成为止。
这些递归会话不会计入会话限制，非活动会话处于空闲等待事件而不消耗资源。
递归会话肯定是优化器所需的递归SQL的结果，其中缺少优化器统计信息（如GTT的情况）和optimizer_dynamic_sampling的初始化参数设置为4。
我们前几天看到的50,000个会话可能是由于运行了几千个选择语句（我个人每个查询计算了20个递归会话，但这个数字可能会有所不同）。
ADDM报告显示影响不大：
查找4：会话连接和断开连接
影响是.3 [平均]活动会话，占活动总数的6.27％[当前在实例上]。
平均活动会话数是数据库负载的度量值（接近CPU计数的值将被视为高）。您的实例最多可以处理32个活动会话，因此影响大约是容量的1/100。