oracle用户资源限制未生效的根本原因是其进程未通过pam加载limits.conf，需检查真实进程的/proc/pid/limits；必须soft/hard成对配置、避免*通配符、优先修改limits.d下预装文件，并确保nr_open内核参数足够。

为什么改了/etc/security/limits.conf但ulimit -n还是1024

根本不是配置写错了，而是 Oracle 用户压根没走 PAM 加载这行限制。常见于：su oracle（不带-）这种非 login shell 场景，或 systemd 服务直接启动 Oracle 实例——两者都不触发 pam_limits.so。确认是否生效，不能只看当前终端的 ulimit -n，得查真实 Oracle 进程：ps -u oracle -o pid,comm | grep pmon → cat /proc/<pid>/limits | grep "Max open files"</pid>。

oracle用户必须成对配soft和hard值

Oracle 19c 启动时会尝试把文件描述符上限提升到 hard 值；如果只写了 soft，它可能卡在共享内存段分配阶段，报 ORA-27123: unable to attach to shared memory segment。必须同时写：

• oracle soft nofile 65536
• oracle hard nofile 65536
• oracle soft nproc 16384
• oracle hard nproc 16384
• oracle soft stack 10240
• oracle hard stack 32768

别用*通配符——limits.conf是用户名精确匹配，*只对 root 或未指定用户生效，对 oracle 无效。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

优先级陷阱：/etc/security/limits.d/里的文件会覆盖limits.conf

Oracle 19c 安装包自带的 oracle-database-preinstall-19c.conf 就放在 /etc/security/limits.d/ 下，且该目录下文件按字母序加载，20-nproc.conf、oracle-database-preinstall-19c.conf 都比 limits.conf 优先级高。如果你手动改了 limits.conf 却没生效，先检查：ls /etc/security/limits.d/，再用 grep -r "oracle.*nofile" /etc/security/limits.d/ 看有没有冲突定义。建议直接修改 oracle-database-preinstall-19c.conf，避免被覆盖。

数值不能瞎设：受内核/proc/sys/fs/nr_open硬约束

就算你在 limits.conf 里写 oracle hard nofile 100000，只要系统 /proc/sys/fs/nr_open 是默认的 1048576，实际生效上限就是 nr_open 值除以线程数后的结果，且 Linux 会静默截断超限值。验证方法：cat /proc/sys/fs/nr_open，确保它 ≥ 2×你设的 hard nofile 值（留出 kernel 线程余量）。若需调高，得同步改 /etc/sysctl.conf 并执行 sysctl -p。

真正生效的关键不在“写了什么”，而在“谁以什么方式启动了 Oracle 进程”——login shell、systemd service、cron job、甚至 su 的参数差异，都会让同一份 limits.conf 在不同上下文里彻底失效。