ORA-12518 根本原因是 Oracle 实例进程耗尽，需确认 v$process 占用率 ≥90%上限、processes 参数已通过 spfile 修改且数据库重启生效，并排除 ulimit 系统限制、监听/服务启动顺序错误及 SGA/PGA 内存不足等干扰因素。
ora-12518 不是 navicat 的问题，而是 oracle 实例已无可用进程来承接新连接。你调大 processes 参数是对的，但必须确认当前值确实接近上限、且修改后已生效——否则只是白改。
怎么确认真是 processes 不够用
别凭感觉，直接查数据库状态：
- 连上数据库（用
sqlplus / as sysdba）后执行：SELECT COUNT(*) FROM v$process;—— 这是当前真实占用的进程数 - 再查上限：
SELECT value FROM v$parameter WHERE name = 'processes'; - 如果前者 ≥ 后者 × 0.9，基本就是瓶颈了；若两者相等，新连接必失败
- 注意：
v$process包含后台进程（如 PMON、DBW0），不全是客户端连接，但总量超限一样阻塞分发
改了 processes=1000 为什么还是报错
常见失效原因有三个：
-
SCOPE=spfile修改只写入服务器参数文件，数据库必须重启才加载——没重启等于没改 - Linux 系统级限制卡死了 Oracle 用户：
执行ulimit -u查看当前用户最大进程数，若低于你设的processes值（比如只允许 1024，而你设了 2000），Oracle 启动时会静默截断为系统上限 - Windows 上服务未按顺序重启：必须先停
OracleService<SID>，再停OracleOraDB<ver>home<n>TNSListener，再启服务；反序或只重启监听，processes新值根本不会被读取
processes 和 sessions 的关系不能硬套公式
很多资料说 sessions = 1.1 × processes + 5，但这是旧版规则。19c 及以后版本实际换算更复杂，且 sessions 是派生值，**不要手动设 sessions**：
- 只改
processes，Oracle 会自动算出对应sessions上限 - 手动设
sessions反而可能冲突：比如processes=1000本该对应约 1528 个会话，你却设成 1200，等于人为缩容 - 验证是否生效：重启后查
SELECT value FROM v$parameter WHERE name IN ('processes', 'sessions');，看两个值是否合理匹配
真正容易被忽略的是：即使 processes 调高了，如果操作系统 ulimit 或数据库内存（SGA/PGA）吃紧，Oracle 仍可能在 fork 新进程时失败——此时错误日志里往往伴随 ORA-27300 类系统级报错，得一并检查。
