ora-27300是操作系统资源配额被卡死的明确信号，需结合status值定位：status 12（enomem）查aio-max-nr和ulimit -l；status 11（eagain）查ulimit -u；status 22/36查removeipc=yes误删ipc；三处配置（aio-max-nr、ulimit、removeipc）必须在rac所有节点完全一致。
ORA-27300 出现在 alert 日志里，**基本不是数据库配置或 SQL 问题，而是操作系统资源配额被卡死的明确信号**。它本身不描述具体错误，只说明 Oracle 在调用某个系统函数（如 semget、sendmsg、fork）时失败了，真正的线索藏在紧随其后的 status 值和 ORA-27301 的 OS 错误消息里。
看 status 值才能定位真实原因
ORA-27300 后面的 status 是 Unix 系统错误码（来自 errno.h），必须查它才能知道到底卡在哪：
-
status: 12→ENOMEM：内存不足，常见于aio-max-nr耗尽或ulimit -l不够（尤其启用了大页） -
status: 11→EAGAIN：进程数超限，ulimit -u小于实例所需总进程数 -
status: 22→EINVAL：参数非法，典型是semctl调用时信号量 ID 已失效（常因RemoveIPC=yes导致） -
status: 36→ENOSYS或EIDRM：IPC 对象被删，99% 是systemd-logind清理了信号量/共享内存 -
status: 105→ENOBUFS：网络缓冲区不足，需调vm.min_free_kbytes和回环接口MTU
检查 /proc/sys/fs/aio-max-nr 是否被占满
Oracle 19c RAC 默认启用异步 I/O，每个实例会批量申请 AIO 控制块，aio-max-nr 是全系统总上限，不按用户隔离：
- 运行
cat /proc/sys/fs/aio-max-nr：RAC 生产环境建议 ≥1048576 - 运行
cat /proc/sys/fs/aio-nr：若接近aio-max-nr，说明已被占满——旧实例崩溃后未清理 AIO 资源是常见原因 - 临时修复：
echo 1048576 > /proc/sys/fs/aio-max-nr；永久生效需在/etc/sysctl.conf加fs.aio-max-nr = 1048576
确认 systemd-logind 的 RemoveIPC 没有误删信号量
RHEL/CentOS 7+ 默认 RemoveIPC=yes，只要最后一个 oracle 或 grid 用户登出，系统就清空其所有 IPC 资源——ASM 或 DB 实例会瞬间失去信号量而崩溃，重启时报 semget failed: No space left on device（实际是“没信号量可用了”）：
- 检查：
grep RemoveIPC /etc/systemd/logind.conf，输出为RemoveIPC=yes就是根源 - 修复：改为
RemoveIPC=no，然后执行systemctl daemon-reload和systemctl restart systemd-logind - 注意：该设置必须在所有 RAC 节点上完全一致，否则一节点正常、另一节点反复宕机
验证 ulimit 设置是否匹配实例规模
Oracle 进程既 fork 子进程又发大量 AIO 请求，ulimit -a 里三个值必须同时达标：
-
max user processes (-u)：至少 ≥PROCESSES × 节点数 × 1.3，生产建议直接设为16384或更高 -
max locked memory (-l)：若use_large_pages=only，此项必须为unlimited，否则sskgpcreates直接失败 -
open files (-n)：RAC 心跳、ASM、监听器都依赖它，低于65536时连touch test.txt都可能报错 - 改完
/etc/security/limits.conf后，必须用su - oracle重新登录终端，ulimit -a才生效
真正麻烦的不是单点配置，而是 RAC 多节点间这三处（aio-max-nr、ulimit、RemoveIPC）必须完全一致——漏掉一个节点，故障就会周期性出现在那个节点上，日志里 ORA-27300 看似随机，实则精准指向配置漂移点。
