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 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西
相关推荐
Mr.Daozhi9 分钟前
RAG 进阶实战:跑通 Demo 后我连续翻了 6 次车,逐一修复才真正可用(含 Gradio Web 版)安替-AnTi10 分钟前
厚朴 APK 搜索接口分析小程故事多_8014 分钟前
Claude Code自定义workflow skills用法大鹏说大话15 分钟前
SQL 排序与分组实战:解决“分组后取最新数据“plainGeekDev29 分钟前
Android运行时面试题:ART和JVM的区别都搞不清,别写精通了山川湖海33 分钟前
AI时代快速学编程语言的陷阱(以Python为例)H Journey37 分钟前
Supervisor 进程管理工具介绍夏贰四1 小时前
数据建模工具如何筑牢数据根基?数据建模工具怎样落实标准体系?春日见1 小时前
5分钟入门强化学习之动态规划算法与实现DeniuHe2 小时前
sklearn 中所有交叉验证数据集划分方式完整总结