Oracle 12c在线移动数据文件必须满足硬性条件：先查v$datafile确认name、status和online_status均为ONLINE；仅限普通用户表空间（禁动SYSTEM/SYSAUX/UNDO）；CDB/PDB下须切换至对应容器；KEEP需显式指定，REUSE用于覆盖目标同名文件，不加参数默认删除源文件。
能，但必须满足几个硬性条件，否则看似“在线”，实则卡住 checkpoint、阻塞 smon，甚至导致实例无法 shutdown 或 startup。
确认数据文件状态是否真正 ONLINE
别只查 dba_data_files —— 它不反映实时在线状态。迁移前必须执行：
SELECT name, status, online_status FROM v$datafile WHERE name = '<your_file_path>';
两个字段都得是 ONLINE 才能继续。常见错误是文件 status 为 ONLINE，但 online_status 是 OFFLINE 或 RECOVER，这时执行 ALTER DATABASE MOVE DATAFILE 会直接报错或挂起。
避开 SYSTEM/SYSAUX/UNDO 表空间的坑
技术上 Oracle 12c 允许移动这些文件，但生产环境严禁操作。原因不是语法不支持，而是：
- 迁移中断时，SMON 可能卡在 block cleanout，后续 DML 会 hang
- checkpoint 进程被阻塞，
shutdown immediate会无限等待 - 实例重启时控制文件与数据文件头校验失败，报
ORA-01122或启动失败
只对 USERS、TBS_APP 等普通用户表空间的数据文件用 MOVE DATAFILE —— 这才是设计初衷的安全边界。
多租户（CDB/PDB）下必须切换到对应容器
在 root 容器里执行 ALTER DATABASE MOVE DATAFILE 操作 PDB 的文件，哪怕路径完全正确，也会报 ORA-01516：“nonexistent data file”。正确做法是：
- 先
ALTER SESSION SET CONTAINER = <pdb_name>; - 再确认该 PDB 处于
OPEN状态（SELECT open_mode FROM v$pdbs） - 最后执行命令。PDB 的
SYSTEM文件虽仍不推荐移动，但至少语法层面允许（且比 CDB 的 SYSTEM 风险略低）
KEEP 和 REUSE 参数的实际影响
不加参数默认删除源文件（OS 层 mv 语义），这是最常用也最干净的方式。但要注意：
-
REUSE：目标路径已有同名文件时覆盖，不报错。适合 ASM 到 ASM 迁移中目标磁盘组残留旧文件的场景 -
KEEP：源文件保留，仅更新控制文件指向。Windows 平台下即使不写KEEP也可能残留源文件，必须显式指定才可靠 - 误用
KEEP后忘记清理旧文件，会导致空间浪费 + DBA 误判文件位置，后续备份或 RMAN catalog 可能出错
真正容易被忽略的是：迁移完成后，v$datafile 中路径已更新，但 OS 层文件权限、SELinux 上下文、ASM diskgroup 权限等未必自动继承 —— 必须手动验证新路径的 I/O 可读写，否则下次 checkpoint 或 backup 就会失败。
