ora-27041是oracle“无法打开文件”的通用报错，根本原因需结合os错误码判断：error 13为权限不足，error 2为文件不存在，error 24（too many open files）则指向ulimit -n限制过低，常见于rman备份、归档高并发或大量数据文件场景。
ora-27041 报错本身不说明根本原因，它只是“无法打开文件”的笼统提示；真正要盯的是错误附带的 os 级信息（比如 error: 13: permission denied 或 error: 2: no such file or directory），而当它和备份并发、rman 长时间运行或大量归档生成一起出现时，ulimit -n 不足是高频诱因。
查 ulimit 是否卡在 1024
Oracle 进程（尤其是 RMAN、LGWR、ARCn）在高并发归档、多通道备份或挂载大量数据文件时，很容易突破默认 1024 个文件描述符限制。一旦触顶，后续 open() 系统调用就会失败并报 ORA-27041，且常伴随 Error: 24: Too many open files（注意：不是 Error 2 或 13）。
验证方法很简单：
- 用 Oracle 启动用户（如
oracle）登录，执行ulimit -n—— 若输出是1024或更低，就是瓶颈 - 进一步确认当前进程实际使用量：
lsof -u oracle | wc -l，对比ulimit -n值 - 检查 RMAN 备份日志中是否在报错前出现过
WARNING: too many open files类提示
改 /etc/security/limits.conf 而非 /etc/system
现代 Linux（RHEL/CentOS 7+、Oracle Linux 7+）已弃用 /etc/system，改用 /etc/security/limits.conf 或 /etc/security/limits.d/*.conf。硬写 /etc/system 不生效，还可能引发其他服务异常。
正确做法是追加以下两行到 /etc/security/limits.conf：
oracle soft nofile 65536 oracle hard nofile 65536
注意：
- 用户名必须与 Oracle 实际运行用户一致（
id -un确认），不能写成* soft nofile - 修改后需重新以该用户登录（或重启会话），
su - oracle不够，必须完整登录 shell - 若使用 systemd（如 OL8+），还需检查
/etc/systemd/system.conf中DefaultLimitNOFILE=是否被设为低值，它会覆盖 limits.conf
RMAN 启动脚本里补 ulimit
即使系统级 limits 设对了，某些通过 cron、OEM 或自定义脚本触发的 RMAN 任务仍可能继承父进程的旧限制（尤其当脚本未显式 su - oracle）。最稳妥的方式是在 RMAN 调用前强制重置：
例如，在你的备份脚本开头加入：
ulimit -n 65536 export ORACLE_SID=ORCL export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1 rman target / @backup_full.rman
关键点：
- 必须在
rman命令之前执行ulimit，且不能放在子 shell 里（如(ulimit -n 65536; rman ...)无效） - 如果脚本用
#!/bin/bash -l，确保 login shell 加载了 limits.conf；否则加ulimit更可靠 - 避免在脚本里写
ulimit -n 1024—— 这是很多旧模板的坑，直接锁死上限
别忽略 ASM 和 NFS 挂载点的隐藏限制
当控制文件、归档日志或备份片存放在 ASM diskgroup 或 NFS 共享路径时，ORA-27041 可能表面是权限问题，实则是底层连接数耗尽：
- ASM 实例本身也有文件描述符限制，需同步检查
grid用户的ulimit -n - NFS 客户端默认
nfsvers=3时，每个 mount 会占用多个 socket 和文件句柄；升级到nfsvers=4.1并启用noac可显著降低开销 - 用
cat /proc/mounts | grep nfs查看实际挂载参数，确认没带hard,intr,nolock等易导致句柄泄漏的选项
这类问题不会在 ulimit -n 里暴露，但 lsof -p $(pgrep -f "ora_pmon") | grep nfs 会看到大量 REG 类型句柄堆积——此时单调高 ulimit 无效，得调 NFS 参数或换存储路径。
