rman在oracle 12c中禁止备份处于在线移动（moving）状态的数据文件，直接报ora-19695错误；必须等待v$datafile.status恢复为online且v$session_longops无相关长操作后方可备份，无绕过方法。
rman 在 oracle 12c 中无法备份正在执行在线移动（alter database move datafile）的数据文件，不是因为命令写错或权限不足，而是数据库内核主动阻止该操作——数据文件处于“moving”状态时，rman 会直接报错拒绝备份。
ORA-19695 错误：RMAN 拒绝备份 moving 状态的数据文件
典型错误信息是：ORA-19695: datafile string is being moved online, cannot backup or copy。这个错误在 RMAN 尝试访问该文件时立即抛出，不进入读取阶段，也不生成任何备份片。
原因很直接：Oracle 在 v$datafile 和内部文件状态标记中将 moving 中的文件设为不可读/不可拷贝状态，RMAN 的校验逻辑会在打开文件前检查该标记，一旦发现 status = 'MOVING'（查 v$datafile.status 可确认），就直接中断。
- 该限制与归档模式、只读状态、备份优化配置完全无关——哪怕你用
BACKUP FORCE或显式指定文件号，照样报错 -
MOVE DATAFILE是原子性操作，但耗时取决于文件大小和 I/O 压力；RMAN 不会等待它完成，而是立刻拒绝 - 即使文件只是“刚发起 move”，还没真正开始物理拷贝（比如卡在锁等待或 checkpoint 阶段），状态已置为 MOVING，RMAN 同样拦停
如何确认某个数据文件正处于 moving 状态
别只看 SQL*Plus 是否返回成功——ALTER DATABASE MOVE DATAFILE 执行后可能返回 “Statement processed”，但后台任务仍在跑。必须查动态视图：
- 运行
SELECT file#, name, status FROM v$datafile WHERE status = 'MOVING';—— 如果有结果，说明文件还在移动中 - 查
v$session_longops：过滤opname LIKE '%move%'，看是否仍有活跃 long operation - 查
v$backup_set_details或 RMAN 日志，找不到该文件的备份记录，不是遗漏，是根本没被纳入扫描范围
注意：dba_data_files.status 不反映 moving 状态，它始终显示 AVAILABLE；只有 v$datafile.status 才真实。
RMAN 备份前必须等 moving 完成，不能绕过
没有合法的 RMAN 参数或隐含参数能跳过这个检查。试图用以下方式均无效：
-
BACKUP DATAFILE <file> FORCE</file>：FORCE 不覆盖 moving 拦截 -
BACKUP AS COPY：同样触发 ORA-19695 - 在 RMAN 脚本里加
SET COMMAND ID或ALLOCATE CHANNEL：通道分配不受影响，但实际备份时仍失败 - 切换到另一个通道类型（如 SBT）：错误与介质无关，是内核级拒绝
唯一可靠做法是：等 v$datafile.status 恢复为 ONLINE（且 v$session_longops 无相关 longops），再执行备份。可加简单轮询脚本：
while [ $(sqlplus -s / as sysdba <hr><h3><h3>为什么不能像处理 offline 文件那样 skip？</h3></h3><p>RMAN 对 <code>OFFLINE</code> 文件默认跳过并记日志（<code>skipping offline datafile</code>），但对 <code>MOVING</code> 文件选择硬拦截，是因为：</p>
- offline 文件内容静态、可预测；moving 文件内容正在重写，任意时刻读取都可能拿到不一致块（类似 open backup 的风险，但更严重）
- Oracle 不提供 moving 过程中的 block-level 一致性保证，RMAN 无法做 block checksum 校验，也不敢假设 SCN 有效性
- 该设计避免 DBA 误以为“备份成功”，实则得到损坏备份片——宁可失败，也不给虚假安全感
所以，看到 ORA-19695，第一反应不该是调参数，而是去查 v$datafile 和长操作视图，确认 moving 是否真结束。这一步漏掉，后面所有重试都是徒劳。
