ora-01122/ora-01110报错主因是数据文件卡在备份模式未退出，需查v$datafile确认file#，逐个执行alter database datafile end backup；归档缺失或控制文件路径失效亦会导致失败。
ora-01122 / ora-01110 报错说明备份模式没正确退出
执行 alter database end backup 后仍报这类错误，基本是某个数据文件卡在备份模式里没真正退出。oracle 不会自动清理异常中断的备份状态，得手动确认并修复。
- 先查哪些文件还在备份模式：
SELECT file#, name, status FROM v$datafile WHERE status = 'BACKUP';
- 如果返回结果非空，说明对应
file#的数据文件仍被冻结，END BACKUP没生效或只执行了部分 - 常见原因是执行时用了
ALTER DATABASE ARCHIVELOG或实例崩溃后恢复不完整，导致控制文件和数据文件头状态不一致
用 ALTER DATABASE DATAFILE ... END BACKUP 逐个解冻
当 ALTER DATABASE END BACKUP 失效，必须按文件号单独处理。这是最稳妥、也最常被忽略的操作路径。
- 对每个卡住的
file#，运行：ALTER DATABASE DATAFILE <file_number> END BACKUP;</file_number>
（例如ALTER DATABASE DATAFILE 3 END BACKUP;） - 不能用文件路径代替编号——
v$datafile.name是路径，但语法只认file# - 若报
ORA-01145（需在 MOUNT 状态下操作），说明数据库是 OPEN 状态，而该文件头仍标记为“热备中”，此时强制执行可能损坏一致性；应先确认归档是否完整，再考虑重启到 MOUNT 后重试
归档日志缺失会导致 END BACKUP 失败
Oracle 要求所有处于备份模式的数据文件，在退出前必须完成对应时间点的归档日志切换。缺日志，就卡住。
- 检查归档是否堆积：
ARCHIVE LOG LIST;
和SELECT * FROM v$archive_gap;
- 若有 gap，必须先用
COPY或 RMAN 从备份介质补全缺失归档，再执行RECOVER DATABASE UNTIL CANCEL（手动输入AUTO），让控制文件认可日志链完整 - RAC 环境下尤其注意：不同节点归档路径不一致、或某节点归档进程挂起，都可能导致
END BACKUP在部分节点失败
误删 backup 控制文件副本也会触发假冻结
冷备份时如果复制了控制文件，但后续删了其中一个副本，Oracle 可能误判为“备份未结束”，尤其在使用 ALTER DATABASE BACKUP CONTROLFILE TO TRACE 后又清空 trace 目录的情况。
- 查当前控制文件列表：
SELECT name FROM v$controlfile;
- 确保每个路径真实可读；若发现某路径已不存在（如磁盘卸载、权限丢失），需用
ALTER SYSTEM SET control_files='...' SCOPE=SPFILE更新，并重启实例 - 这个现象不会报明确错误，但
v$datafile.status会长期显示BACKUP，本质是 Oracle 内部校验机制把缺失的控制文件副本当作“未完成的备份上下文”
事情说清了就结束。最麻烦的是状态不一致+归档断链+控制文件路径失效三者叠加，这时候光靠 END BACKUP 没用，得一层层验。
