oracle用户文件描述符限制必须在limits.conf中同时配置soft和hard值，否则实例可能因ora-27123等错误静默失败；systemd系统还需通过override.conf设置limitnofile，否则服务进程不继承limits.conf配置。
limits.conf 配置必须成对设置 soft 和 hard
Oracle 启动时会检查 nofile 和 nproc 的 soft 限制，但某些版本（如 12cR2+、19c）会尝试调用 setrlimit() 提升到 hard 上限——如果 hard 没设或低于 soft，进程可能因权限不足失败，典型报错是 ORA-27123: unable to attach to shared memory segment。
-
oracle soft nofile 65536和oracle hard nofile 65536必须同时存在，不能只写 soft 行 -
oracle soft nproc 2047和oracle hard nproc 16384同理，nproc 控制最大进程数，Oracle 后台进程（如ora_pmon_*）密集时容易触达 - 不要用
*通配符，limits.conf对用户名精确匹配，写成* soft nofile 65536对 oracle 用户完全无效 - 数值不能盲目设高：内核参数
/proc/sys/fs/nr_open是硬上限，比如值为1048576，你设2000000会被静默截断为1048576
为什么 ulimit -n 显示正确但 Oracle 还是启动失败？
因为 ulimit -n 查的是当前 shell 的限制，而 Oracle 实例由后台服务启动，实际继承的是其父进程的 limits——常见于没走 PAM 认证的场景。
- 用
su oracle（不带-）切换用户，不会加载limits.conf，必须用su - oracle或 SSH 直连 - systemd 管理的 Oracle 服务（如
systemctl start oracle-db）默认绕过 PAM，limits.conf完全不生效 - 验证是否真生效：先找
ora_pmon_<sid></sid>进程 PID：ps -u oracle -o pid,comm | grep pmon，再查cat /proc/<pid>/limits | grep "Max open files"</pid>，输出应为类似65536 65536 files
systemd 环境下必须显式配置 LimitNOFILE
现代 Oracle 部署（尤其 RPM 包安装或云平台）基本依赖 systemd，此时 /etc/security/limits.conf 只对交互式 login shell 有效，服务进程需单独声明资源限制。
- 编辑对应 service 文件，如
/usr/lib/systemd/system/oracle-db.service或/etc/systemd/system/oracle-db.service - 在
[Service]小节下添加：LimitNOFILE=65536，也可加LimitNPROC=16384 - 改完后执行：
systemctl daemon-reload && systemctl restart oracle-db - 注意：RAC 环境每个节点都要单独配置并验证，不能复用同一份 service 文件
pam_limits.so 必须启用且位置合理
limits.conf 生效的前提是 PAM 加载了 pam_limits.so 模块，但模块是否被调用、何时被调用，取决于它在 PAM 配置文件中的位置和条件。
- 检查
/etc/pam.d/login或/etc/pam.d/sshd是否含session required pam_limits.so；若没有，手动添加 - 该行不能放在
auth段，必须在session段，且建议放在靠前位置（避免被其他 module 覆盖） - 某些发行版（如较新 RHEL/CentOS）默认已启用，但自定义镜像或最小化安装常缺失，需人工补全
-
/etc/pam.d/system-auth里也有该行，但它主要影响本地登录；远程 SSH 登录依赖的是/etc/pam.d/sshd
真正生效的关键不在配置写了多少行，而在 Oracle 进程启动那一刻，它的 /proc/<pid>/limits</pid> 里看到的数字。哪怕 limits.conf 写得再全，只要没经过 PAM 或 systemd 没显式设限，就只是纸上谈兵。
