能恢复，但必须停库到MOUNT状态，且需同时满足：有对应数据文件的RMAN备份、归档日志链连续、控制文件完好；OPEN状态下内核拒绝覆盖被DBWn读写的文件，SCN持续更新导致物理覆盖会破坏一致性，故必须SHUTDOWN IMMEDIATE再STARTUP MOUNT。
能恢复，但必须停库到 MOUNT 状态，且缺一不可：有对应数据文件的 RMAN 备份、归档日志链连续、控制文件完好。
为什么不能在 OPEN 状态下直接 RESTORE DATAFILE
Oracle 内核会拒绝覆盖正在被 DBWn 进程读写的文件。此时执行 RESTORE DATAFILE，RMAN 不是真找不到备份，而是被状态拦截——常见报错 RMAN-06023: no backup or copy of datafile x found to restore，实际是权限/状态拒绝，不是备份缺失。数据库仍在运行时，控制文件和数据文件头的 SCN 持续更新，物理覆盖会导致一致性崩溃。
用户表空间文件误删后实例通常还能跑，但访问相关对象会报 ORA-01116、ORA-01110；系统表空间（如 SYSTEM）文件丢了，实例大概率已自动宕机，直接 STARTUP MOUNT 即可。
- 必须先
SHUTDOWN IMMEDIATE，再STARTUP MOUNT - 验证状态：
SELECT status FROM v$instance;输出必须是MOUNTED - 切勿用
ALTER DATABASE DATAFILE ... OFFLINE DROP——这会从控制文件抹除记录，后续SWITCH或RECOVER全部失效
RESTORE 和 RECOVER 必须成对执行
RESTORE DATAFILE 只是把备份片解压拷贝到磁盘，得到的是“冷副本”，其数据块 SCN 滞后于当前控制文件；RECOVER DATAFILE 才真正应用归档日志前滚，修复事务一致性。跳过后者直接 ONLINE，必然触发 ORA-01113: file X needs media recovery。
- 路径必须与
v$datafile中完全一致：大小写、斜杠方向（Linux/macOS 用/，Windows 建议也统一用/）都不能错 -
RECOVER DATAFILE自动查找所需归档；若缺失，报ORA-00279或RMAN-06054 - 归档分散在多个位置？用
SET ARCHIVELOG DESTINATION TO '/path'指定搜索路径（需在RUN块内、命令前）
恢复完成后 ONLINE 前的关键校验
别急着 ALTER DATABASE DATAFILE ... ONLINE，先确认两件事：
- 文件权限：Oracle 进程（如
oracle用户）必须对还原后的文件有读写权限，否则报ORA-01157: cannot identify/lock data file - 路径未被手动改名：如果误删后有人重建了同名空文件，RMAN 还原会失败；应先
rm掉它，再执行RESTORE - 若权限或路径出问题，可用
ALTER DATABASE RENAME FILE 'old' TO 'new';修正后再RECOVER
整个流程最脆弱的环节是归档日志连续性——哪怕只缺一个归档，RECOVER 就卡住不动。备份策略里必须确保归档至少保留到上次全备之后，并定期验证 RESTORE ARCHIVELOG 可读性。
