能在线移动普通用户表空间数据文件；SYSTEM、SYSAUX、UNDO、tempfile、控制文件、日志文件均不支持。须查v$datafile确认file#、name、status、online_status均为ONLINE，CDB/PDB需先切换容器，迁移后须手动更新统计信息。
能，但仅限普通用户表空间的数据文件；SYSTEM、SYSAUX、UNDO、tempfile、控制文件、日志文件一律不能用 ALTER DATABASE MOVE DATAFILE 在线移动。
确认目标数据文件是否真正可在线移动
别只查 DBA_DATA_FILES —— 它不反映实时状态。必须执行：
SELECT file#, name, status, online_status FROM v$datafile WHERE name = '/path/to/your/file.dbf';
两个字段都必须是 'ONLINE' 才能安全操作。若 status 为 'RECOVER' 或 online_status 为 'OFFLINE'，命令会挂起或报错，甚至卡住 checkpoint。
- 只对
USERS、TBS_APP等普通用户表空间操作 - 绝对避开
SYSTEM、SYSAUX、UNDOTBS1、TEMP表空间的文件 - 临时文件（
tempfile）不支持该命令，别试
MOVE DATAFILE 的 KEEP / REUSE 参数怎么选
语法统一为：ALTER DATABASE MOVE DATAFILE '，但选项决定底层行为：
- 不加任何选项：源文件被删除（类似
mv），空间立即释放，最常用 -
REUSE：目标路径已存在同名文件时直接覆盖（不报错），适合 ASM 到 ASM 迁移中目标磁盘组残留旧文件的场景 -
KEEP：保留源文件，只更新控制文件指向新位置；可用于灰度验证，但必须手动清理旧文件，否则浪费空间且易混淆 -
KEEP在 OMF（Oracle Managed Files）环境下不可用
多租户（CDB/PDB）下容易漏掉的关键上下文
在 CDB 中直接执行会报 ORA-01516（“nonexistent data file”），哪怕文件物理存在。
- 必须先切换到对应 PDB：
ALTER SESSION SET CONTAINER = pdb_name; - 再查
v$datafile和执行MOVE DATAFILE - 如果目标是 ASM，
TO子句可省略（自动按DB_CREATE_FILE_DEST生成 OMF 名），但非 ASM 路径必须显式指定完整目标文件名
迁移后性能突然下降？大概率是统计信息没更新
MOVE DATAFILE 不触发统计信息收集，也不刷新执行计划缓存。结果就是：
-
DBA_DATA_FILES.BYTES可能不准，DBA_SEGMENTS中大小滞后 - 优化器误判数据分布，分区裁剪失效，全表扫描变多
- 动态采样可能临时补救，但对倾斜数据不可靠
立刻执行：DBMS_STATS.GATHER_DATABASE_STATS 或至少针对相关表空间跑一次 DBMS_STATS.GATHER_SCHEMA_STATS。别等“业务反馈慢了”才想起来。
真正危险的不是命令本身失败，而是它成功执行了，但没人检查 v$datafile 状态、没人切容器、没人清旧文件、没人更新统计信息——这些点一旦漏掉，问题会延后爆发，排查成本翻倍。
