如何排查并改写Oracle 19c RAC中ORA-27300错误涉及的操作系统异步IO限制与权限问题？

本文共计1254个文字，预计阅读时间需要6分钟。

相关专题

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 阶段。