ORA-00020 根本原因是 Oracle 实例 process 限额被耗尽,需联合 vprocess 与 vsession 按 machine 和 program 分组统计,结合服务注册中心定位异常节点;HikariCP 的 maximumPoolSize 仅控制单节点池大小,实际占用取决于节点数×单节点连接数,且须检查 JDBC 隐式缓存、连接泄漏及 OS 层 ulimit 限制,调大 processes 后需同步调整 sessions 并重启数据库。Oracle报 ORA-00020: maximum number of processes exceeded 怎么快速定位是哪个应用节点撑爆的直接查 vprocess 和 vsession 联合过滤,别只盯着 vresource_limit 看上限------它只反映历史峰值,不反映当前谁在占坑。重点看 program 和 machine 字段,微服务里通常 program 是统一的 jdbc 驱动名(如 jdbc thin client),但 machine 会暴露真实宿主机或 pod ip。配合你自己的服务注册中心(比如 nacos/eureka)反查 ip 对应的服务名和实例 id。执行 SELECT machine, program, COUNT(\*) FROM vprocess p JOIN vsession s ON p.addr = s.paddr GROUP BY machine, program ORDER BY COUNT(\*) DESC;如果用的是 Kubernetes,machine 常是容器内 hostname,需提前在启动脚本里把 hostname 设为 (POD_NAME).$(NAMESPACE) 或写入 client_info(用 DBMS_APPLICATION_INFO.SET_CLIENT_INFO)注意:连接未正确 close 的"幽灵连接"可能显示 STATUS = INACTIVE 但 LOGON_TIME 很老,这类要结合 LAST_CALL_ET 判断是否真空闲Spring Boot + HikariCP 下改 maximumPoolSize 为什么没让 Oracle 连接数降下来HikariCP 的 maximumPoolSize 控制的是本地连接池大小,但 Oracle 的 processes 是实例级硬限,每个 TCP 连接进来都会消耗一个 process slot------哪怕连接池里只开 5 个连接,如果 10 个微服务节点各连一次,就占掉 10 个 process。真正起作用的是每个节点的连接池配置 × 节点数量,不是单个节点的池大小确认是否启用了连接复用:检查 Oracle JDBC URL 是否带 oracle.jdbc.useImplicitCaching=true,否则即使 HikariCP 回收了连接,底层 socket 仍可能被驱动缓存并维持 process 占用检查 spring.datasource.hikari.leak-detection-threshold 是否开启,避免连接泄露长期霸占 processOracle 12c+ 可启用 SHARED_SERVER 模式(即 MTS),但微服务场景下一般不推荐------共享服务器对短连接友好,但会增加调度开销,且部分 JDBC 功能受限调整 Oracle processes 参数后重启库,应用侧还要做什么光调大 processes 是治标。Oracle 实际能创建的进程还受操作系统限制:kernel.sem(信号量)、ulimit -u(用户最大进程数)、/proc/sys/kernel/pid_max。尤其在容器中,这些值常被默认压得很低。检查宿主机 ulimit -u,确保大于 Oracle 的 processes 值;K8s 中需在 securityContext 里显式设置 runAsUser 和 ulimitsDocker 启动时加 --ulimit nofile=65536:65536 --ulimit nproc=65536:65536,否则 Oracle 启动可能失败或静默降级改完 processes 后,记得同步调大 sessions(建议 sessions = 1.1 * processes),否则登录时可能报 ORA-00018: maximum number of sessions exceeded不要只改 spfile 就完事,用 ALTER SYSTEM SET processes=500 SCOPE=SPFILE; 后必须重启 DB,SCOPE=BOTH 不生效怎么用连接数画像替代"拍脑袋设 MaxActive"靠经验设 maximumPoolSize 容易要么浪费资源,要么突发流量直接打穿。应该基于真实负载建模:统计单位时间、单位接口的平均连接持有时长 × QPS,再叠加缓冲系数。 Cleanup.pictures 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西
相关推荐
WA内核拾荒者20 小时前
WhatsApp账号运营SOP的可视化编排与流水线监控南京云森杉木桩20 小时前
水利木桩源头直供,质量可靠价格更优Aaron - Wistron20 小时前
Python基础教程2/4(复合数据结构)小柯南敲键盘20 小时前
跨境电商图片翻译与视频字幕翻译工具推荐名字还没想好☜21 小时前
Kubernetes StatefulSet 实战:为什么数据库不能用 Deployment 部署ZC跨境爬虫21 小时前
LeetCode 13. 罗马数字转整数(多解法详解 + Java Python 实现)machnerrn21 小时前
智慧交通系列(一)-十字路口车辆闯红灯检测告警抓拍系统(附含数据+源码+模型)现代野蛮人21 小时前
【深度学习实验】—— 利用 RNN 模型进行心脏病预测2601_9563198821 小时前
2026年用示例、拆解和练习提升量化理解效率01_ice21 小时前
MySQL事务