Oracle 19c RAC连接池频繁断开主因是集群节点驱逐、SQLNET.EXPIRE_TIME配置不当、用户profile资源限制或systemd DefaultTasksMax限制，需依次检查alert.log、crsctl状态、sqlnet.ora、DBA_PROFILES及systemd配置。
oracle 19c rac 连接池频繁断开，大概率不是连接池本身的问题，而是底层网络、集群心跳或资源限制在“悄悄起作用”。直接看日志和配置比猜更有效。
查 alert.log 和 crsctl status resource -t 确认是否真为 RAC 节点驱逐
RAC 场景下最典型的“假断连”其实是节点被集群强制驱逐（脑裂），客户端感知为连接突然中断。这不是应用层或连接池能控制的。
- 检查
alert.log中是否有类似ORA-29740、CRS-1612或Instance is being terminated due to fatal process death的记录 - 运行
crsctl status resource -t，重点看ora.database.db和私网资源（如ora.cluster_interconnect.haip）状态是否为ONLINE；若出现UNKNOWN或反复重启，基本锁定集群通信异常 - 私网网卡 MTU 不一致、NTP 时间不同步、防火墙拦截 UDP 123/42422 端口，都可能触发 CRS 驱逐——这些不会在应用日志里报错，但会直接杀掉实例
sqlnet.ora 中 SQLNET.EXPIRE_TIME 设置过小
这个参数控制 Oracle 客户端空闲连接的保活探测频率，RAC 环境下尤其敏感。设得太小（比如 1 分钟），而网络中间设备（如负载均衡器、防火墙）又没做相应超时适配，就会导致连接被单向切断。
- 确认
sqlnet.ora是否设置了SQLNET.EXPIRE_TIME = 10（单位：分钟），这是较稳妥的值；设为 0 则禁用探测，但可能让僵死连接堆积 - 注意：该参数只对服务器端生效，客户端无需配置；修改后需重启监听器（
lsnrctl reload）才生效 - 如果用了 F5 或 Nginx 做连接代理，必须确保其空闲超时 ≥
SQLNET.EXPIRE_TIME+ 30 秒，否则探测包会被丢弃，连接静默断开
检查 DBA_PROFILES 中用户 profile 的 CONNECT_TIME 和 IDLE_TIME
很多团队只改了数据库参数，却忘了用户级资源限制。RAC 下连接池复用的会话一旦超出 profile 限制，就会被数据库主动 kill，现象就是“连接池报错：ORA-02393”。
- 执行
select resource_name, limit from dba_profiles where profile = (select profile from dba_users where username = 'YOUR_APP_USER'); - 重点关注
CONNECT_TIME（会话总存活时间）和IDLE_TIME（空闲时间上限），常见错误是设成10（单位分钟）却没意识到连接池会长期复用同一会话 - 修复方式：用
alter profile YOUR_PROFILE limit connect_time unlimited idle_time unlimited;，或单独为应用用户创建专用 profile 并分配
排查 systemd 的 DefaultTasksMax 限制（仅限 Linux 19c RAC）
这是 Oracle 19c RAC 在 SLES/RHEL 8+ 上特有的坑：systemd 默认限制每个服务最多 fork 512 个进程，而 RAC 的 ASM、GI、DB 实例启动时会大量 fork 子进程。一旦触顶，新连接尝试建立时会静默失败，表现为连接池获取连接超时或瞬间断开。
- 检查当前值：
systemctl show --property DefaultTasksMax，若返回DefaultTasksMax=512就是罪魁祸首 - 临时修复：
sudo systemctl set-property --runtime system.slice DefaultTasksMax=infinity - 永久修复：编辑
/etc/systemd/system.conf，取消注释并修改DefaultTasksMax=infinity，然后sudo systemctl daemon-reload && sudo reboot - 该问题在
ora.database.db资源状态反复变OFFLINE且无明显错误日志时尤为可疑
RAC 连接断开从来不是单一原因，往往是网络抖动触发心跳异常，再叠加 profile 限制或 systemd 限制，形成连锁反应。先盯住 crsctl 和 alert.log，再查 sqlnet.ora 和 DBA_PROFILES，最后别漏掉 systemd 这个隐藏开关——顺序错了，修三天也白搭。
