alter database move datafile 在 oracle 12c 中支持在线移动普通表空间（如 users、tbs_app）数据文件，实现业务无感迁移；但严禁用于 system/sysaux/undo 文件，不支持 tempfile、控制文件和日志文件；须确认 v$datafile 中 status 与 online_status 均为 online，并严格遵循 cdb/pdb 容器上下文及 rac 共享路径要求。
ALTER DATABASE MOVE DATAFILE 在 Oracle 12c 中不是“锦上添花”，而是解决真实运维痛点的关键能力——它让过去必须停机数小时的操作，变成业务无感的后台任务。
哪些场景下非用不可？
当磁盘空间告急（比如 /u01 使用率超 95%）、存储层升级（从本地文件系统迁移到 ASM）、合规要求数据物理隔离（如把某客户表空间挪到专用 LUN），或灾备路径调整时，你没法等一个维护窗口。传统方式要 ALTER TABLESPACE ... OFFLINE → 拷贝文件 → RECOVER → ONLINE，中间 DML 全部阻塞；而 MOVE DATAFILE 允许用户持续读写，只要目标路径 I/O 足够，迁移过程对应用透明。
为什么只推荐用于 USERS/TBS_APP 这类表空间？
-
SYSTEM、SYSAUX、UNDOTBS1文件看似语法能跑通，但迁移中断会卡住 SMON 或 checkpoint，后续SHUTDOWN IMMEDIATE可能无限等待 -
tempfile、控制文件、联机日志根本不支持该命令，硬试会直接报ORA-01516或ORA-01157 - 哪怕查
DBA_DATA_FILES显示文件状态是AVAILABLE，也得确认v$datafile.status = 'ONLINE'且online_status = 'ONLINE'—— 后者才是实时在线标识
KEEP 和 REUSE 参数选错会出什么问题？
默认不加参数 = 源文件被删除（类似 mv），这是最安全的选择；但误用 KEEP 后忘记清理旧文件，会导致：
- RMAN 备份脚本仍尝试备份已失效的源路径，报
ORA-19505 - OS 层磁盘空间没释放，监控告警照常触发
- Windows 或 SELinux 环境下，新路径权限未继承，迁移后文件不可读写，但命令早已返回
Database altered
REUSE 看似省事，但在 ASM 到 ASM 迁移中若目标别名已存在，覆盖操作可能破坏其他 PDB 的同名文件引用——必须先 ls 确认目标 ASM 别名是否干净。
CDB/PDB 和 RAC 环境最容易漏掉的检查点
在多租户中，当前 session 必须在对应 PDB 内执行，否则报 ORA-01516: nonexistent data file，哪怕文件物理存在；RAC 下更危险：命令只在当前节点生效，若目标路径不是共享存储（如 ACFS/ASM），其他节点访问新路径会失败，引发实例级 I/O 错误。迁移前必须在所有节点运行：
SELECT name, state FROM v$asm_diskgroup WHERE name = 'DG_DATA';
确保磁盘组状态为 MOUNTED，且 v$datafile.online_status 在所有节点都为 ONLINE。
v$session_longops 里的 OPNAME = 'move datafile' 才是进度依据，而 alert.log 中的 “Completed online move” 才算落地。
