ORA-27041是Oracle通用系统级文件打开失败错误，根本原因需结合其后紧邻的操作系统错误码判断，常见为路径不存在、权限不足或设备/挂载异常，而非直接指示“文件被占用”；排查须先查alert日志中的OS错误行，再依次验证路径有效性、属主权限、挂载状态及第三方进程占用。
ORA-27041报错本身不指明“被占用”，先确认是不是权限或路径问题
ora-27041是oracle抛出的通用系统级文件打开失败错误，它背后对应的操作系统错误码（如aix的error: 25: not a typewriter、windows的o/s-error: (os 2) 系统找不到指定的文件、linux的permission denied）才是关键线索。它**不是**“文件正被其他进程锁住”的专属提示——那通常是ora-27086（linux）或ora-27041伴随error: 13（hp-ux/windows权限拒绝）才需怀疑占用。
排查顺序必须是：
- 查alert log里
ORA-27041紧邻的OS错误行，例如HPUX-ia64 Error: 13: Permission denied→ 直接看属主和ACL - 检查目标路径是否存在、拼写是否正确（尤其注意大小写、空格、软链接断裂）
- 确认Oracle进程用户（如
oracle）对该路径有rwx权限（目录）和rw权限（文件），在Windows上还要检查“遍历文件夹”和“读取属性”等隐含权限 - 若路径在NFS/ASM/Veritas CFS上，先验证挂载点是否在线、
df -h是否可见、ls -l能否列出内容
真被占用时，Linux下用lsof查谁在读写控制文件或数据文件
当ORA-27041出现在STARTUP MOUNT或RMAN备份中，且同时观察到ORA-00210或ORA-01157，再结合OS错误为Resource temporarily unavailable（即errno=11），才进入“被占用”排查流程。
核心命令是定位持有句柄的非Oracle进程：
-
lsof -p `pgrep -f ora_pmon_<sid>` | grep -i control</sid>—— 查Oracle自身是否异常残留句柄 -
lsof +D /path/to/backup/dir 2>/dev/null | grep -v ora_—— 扫描备份目标目录下是否有veritas、nbu、tivoli等第三方备份代理进程打开了待备份文件 - 特别关注
lk<sid></sid>锁文件：它在$ORACLE_HOME/dbs/下，若存在且ps -ef | grep -i backup无对应进程，说明备份代理异常退出后未清理锁
RMAN备份时遇到ORA-27041，优先检查diskratio参数（AIX特例）
AIX平台下RMAN报ORA-27041并带Error: 25: Not a typewriter，基本可锁定为内核层对裸设备亲和性（affinity）的ioctl调用失败——即使你根本没用裸设备，只要RMAN内部触发了skgfdlndv()函数，就会出错。
绕过方式非常具体：
- 必须显式指定
diskratio=0，例如：backup database format '/bkp/%U' diskratio=0; - 不能只改
FILESPERSET，因为diskratio默认继承该值，仍会尝试探测磁盘亲和性 - 该参数仅影响读取阶段，不影响备份完整性或恢复能力，属于AIX平台已知兼容性补丁
误删文件后出现ORA-27041，别急着restore，先从/proc找句柄恢复
如果ORA-27041出现在数据库运行中，且日志显示“O/S-Error: (OS 2) 系统找不到指定的文件”，而你刚执行过rm，说明文件已被删除但DBW进程仍持有句柄——这是可逆的。
应急恢复步骤紧凑有效：
- 用
ps -ef | grep dbw | grep <sid></sid>找到DBW进程SPID - 执行
ls -l /proc/<spid>/fd/ | grep deleted</spid>，找到类似23 -> /u01/oradata/db/users01.dbf (deleted)的条目 - 立即复制：
cp /proc/<spid>/fd/23 /u01/oradata/db/users01.dbf</spid> - 随后在RMAN中执行
recover datafile N;（无需shutdown），文件即可重新在线
这个操作窗口期很短——一旦DBW进程重启或实例崩溃，句柄释放，就只能走传统restore流程了。
