ORA-27300报open或semget失败，主因是操作系统资源配额被卡死：需检查fs.aio-max-nr（建议≥1048576）、ulimit -u/-l/-n是否匹配实例规模，并禁用systemd-logind的RemoveIPC=yes，且确保RAC各节点三处配置完全一致。
ora-27300 报 open 或 semget 失败，90% 以上不是磁盘空间或文件权限问题，而是操作系统级资源配额被卡死——尤其在 oracle 19c rac 中，async i/o 相关的内核限制、用户 limits、以及 systemd 的 removeipc 行为，三者叠加最容易触发这类错误。
检查 /proc/sys/fs/aio-max-nr 是否被超限
Oracle 19c 默认启用异步 I/O（disk_asynch_io=true），每个实例会批量申请 AIO 事件控制块。若系统全局 AIO 并发上限太低，ksfdopn 或 sskgpcrea 就会因 ENOMEM（status=12）失败。
-
cat /proc/sys/fs/aio-max-nr—— 查当前硬上限；典型 RAC 环境建议 ≥ 1048576（100 万） -
cat /proc/sys/fs/aio-nr—— 查已分配数；若接近aio-max-nr，说明已被占满（常见于未清理的旧实例残留） - 临时调高：
echo 1048576 > /proc/sys/fs/aio-max-nr；永久生效需写入/etc/sysctl.conf加fs.aio-max-nr = 1048576 - 注意：RHEL/CentOS 7+ 中，
aio-max-nr是系统级总配额，不按用户隔离，多实例 RAC 极易撞线
验证 ulimit -a 中 aio 和 nproc 是否匹配实例规模
Oracle 进程启动时既 fork 子进程，又大量发起异步 I/O 请求，ulimit -a 输出里两个值必须同时达标：
-
max user processes (-u)：必须 ≥PROCESSES × 实例数 × 1.3（留后台进程余量）。例如两节点、每节点PROCESSES=800，则至少要设为2080，但生产环境建议 ≥16384 -
max locked memory (-l)：若启用大页（use_large_pages=only），此项必须为unlimited；否则sskgpcreates直接失败，报 status=12 -
open files (-n)：RAC 心跳、ASM 连接、监听器全依赖它，建议 ≥65536；低于此值时，touch test.txt都可能报Too many open files in system - 改完
/etc/security/limits.conf后，必须重新以oracle用户登录终端（su - oracle），ulimit -a才生效
确认 systemd-logind 的 RemoveIPC 没有误删信号量
RHEL/CentOS 7+ 默认开启 RemoveIPC=yes，只要最后一个 oracle 或 grid 用户登出，系统就会自动清理其所属的所有 IPC 资源（包括信号量集和共享内存段）——这会导致正在运行的 ASM 或 DB 实例瞬间失去 IPC 设施而崩溃，并在下次启动时报 semget failed: No space left on device（实际是信号量被删光后无法重建）。
- 检查当前设置：
grep RemoveIPC /etc/systemd/logind.conf；若输出为RemoveIPC=yes，就是罪魁祸首 - 修复方式：
echo "RemoveIPC=no" >> /etc/systemd/logind.conf，然后执行systemctl daemon-reload && systemctl restart systemd-logind - 该配置必须在所有 RAC 节点上统一设置，节点间不一致会导致“一节点能启、另一节点死活起不来”
- 注意：修改后不会恢复已丢失的信号量，需先手动清理残留：
ipcs -s | awk '$3 ~ /^oracle$/ {print $2}' | xargs -I{} ipcrm -s {}
排查 /etc/security/limits.conf 中的 @group 语法是否失效
很多团队习惯用 @dba soft nproc 16384 给组批量设限，但这个写法在 RHEL 7+ 上默认不生效——因为 PAM 模块只认 username 或通配符 *，不解析 @group，导致实际限制仍是系统默认的 4096。
- 验证方法：以
oracle用户执行id，看输出中是否有groups=...1001(dba)；再执行ulimit -u，若仍为4096，说明@dba没生效 - 正确写法是显式指定用户：
oracle soft nproc 16384、grid soft nproc 16384，并确保两行都存在 - 同时检查
/etc/pam.d/login和/etc/pam.d/sshd是否包含session required pam_limits.so；缺一则 limits 不加载 - 若使用 systemd（如通过
systemctl start oracle-database启动），还需额外配置/etc/systemd/system/oracle-database.service.d/limits.conf，否则 limits 对 service 启动无效
真正麻烦的从来不是单点配置，而是 RAC 多节点环境下 /etc/security/limits.conf、systemd-logind.conf、/proc/sys/fs/aio-max-nr 这三处的值在各节点上是否完全一致——差一个数字，就足以让第二个实例永远卡在 startup nomount 阶段。
