ORA-19870是表象错误，根因需看紧随其后的ORA-XXXX（如ORA-19504、ORA-19502、ORA-19573等）；常见原因包括磁盘空间耗尽、ASM磁盘组未挂载、数据库未处于MOUNT状态、目标路径不可写或文件被占用。
ORA-19870 不是独立错误，它只是“症状”，真正的问题藏在它后面的 ORA-XXXX 错误里。 直接查 ORA-19870 没用，必须看 RMAN 输出中紧跟着它的下一条或两条错误（比如 ORA-19504、ORA-19502、ORA-19573、ORA-27072），那才是根因。
ORA-19870 后常跟 ORA-19504：目标路径不可写或磁盘组未挂载
典型场景是恢复到 ASM 或本地文件系统时，目标位置不可用。
-
ORA-19504: failed to create file "+DATA/orcl/control01.ctl"→ 先确认 ASM 磁盘组状态：SELECT name, state FROM v$asm_diskgroup;；若显示DISMOUNTED或UNKNOWN，需用ALTER DISKGROUP DATA MOUNT;（注意权限：用户必须属asmdba组） - 若目标是文件系统路径（如
/u01/oradata/orcl/system01.dbf），检查：df -h /u01（空间是否Use% ≥ 95%）、ls -ld /u01/oradata/orcl/（Oracle 用户是否有写权限）、mount | grep u01（挂载点是否意外卸载） - 在 RAC 或 DG 环境中，还要确认该路径对所有节点都可达——比如 NFS 共享未在某节点执行
mount，就会只在那个节点报ORA-19504
ORA-19870 后常跟 ORA-19502 / ORA-27072：磁盘空间耗尽或 I/O 设备异常
这类组合几乎总是写入失败，但原因不全是“没空间”——得看 block number 和 errno。
-
ORA-19502: write error on file "/u01/.../system01.dbf", block number 34304 (block size=8192)+ORA-27072: File I/O error→ 先运行df -h，重点看目标文件所在分区的Avail列。曾有案例显示Use% = 99%但Avail = 269M，释放几百 MB 即恢复 - 若空间充足，检查内核日志：
dmesg | grep -i "error\|fail\|timeout"，常见输出如end_request: I/O error（硬盘坏道）、NFS: server not responding（NFS 超时）、sg_io: bad/missing sense data（SAN LUN 不可见） - 不要忽略 SELinux：RHEL/CentOS 上若启用了 enforcing 模式，
ls -Z /u01/oradata可能显示 context 不匹配，临时用setenforce 0测试是否缓解
ORA-19870 后常跟 ORA-19573：数据库状态冲突或文件被占用
这个错误明确指向排他锁获取失败，和数据库当前状态强相关。
-
ORA-19573: cannot obtain exclusive enqueue for datafile 1→ 数据库处于OPEN状态。RMAN restore 必须在MOUNT（或NOMOUNT，仅限控制文件）下执行。执行SHUTDOWN IMMEDIATE; STARTUP MOUNT;再重试 - 在异机恢复时，若目标路径下已存在同名数据文件（比如之前恢复中断残留），Linux 层可能因进程未退出导致文件句柄未释放，报
ORA-27086: unable to lock file - already in use。此时用lsof | grep TS_ZSJ_D08.dbf找出 PID 并kill，或直接改用SET NEWNAME FOR DATAFILE指向新路径 - 使用
RESTORE DATABASE时未提前SET NEWNAME，而源库与目标库目录结构不同，RMAN 尝试往只读路径（如/proc下挂载的 tmpfs）写入也会触发此锁失败逻辑
容易被忽略的关键点
DBID 必须正确设置，否则 RMAN 根本找不到备份集，后续所有错误都是假象。在 NOMOUNT 状态下执行 RESTORE CONTROLFILE 前，务必先 SET DBID xxxxxxxxx；如果从备份集中恢复，且控制文件也损坏，DBID 错误会导致 RMAN 完全静默跳过匹配备份片——此时 ORA-19870 实际源于“没找到任何可读的 backup piece”，而非 I/O 故障。
