在awr中看到一些存储过程好像是并行执行其他存储过程的，所以如果只是看job的进程可能不是很完整，应该看所有oracle的进程情况是否超过 process的限制。

由于并发导致大量read by other session，进而影响sql执行效率，大量sql可能都在等待。

建议规划一下并发任务的节点分配，优化gc等待的情况

同时对并发任务的sql进行优化，防止出现热点块导致read by other session的情况

感谢您的回复。

我能确定progress数量没有超过。

也明白您说的这些建议，我会反馈软件厂商。

不过，针对这个问题，还是没有明白为什么不能连接。您看awr可以看到，两个快照间隔了好几个小时，说明oracle统计信息的后台进程都死掉了，无法进行统计信息。

这跟trace的报错和我无法连接数据库都是吻合的。

可是操作系统内存当时富余，free还有2G。可用内存更多。

这块不是很有思路该怎么继续分析分析。还请您在指点一二

数据库使用的是amm内存管理，最好改成asmm，可能由于当时内存争用，导致无法给新的连接分配内存空间。

gc的问题，可以考虑限制并发任务的节点

热点块的问题要针对具体的sql了，对BP_MAIN、BP_ROLE的访问看是否可以优化。