磁盘物理满时应迁移数据文件而非仅关自增长：先用df -h和dba_data_files定位满载磁盘及autoextensible文件，再offline→cp→rename→recover→online完成在线迁移，最后更新备份路径并重开新路径自增长。
磁盘空间已满，但表空间还在自增长，autoextend on 反而成了“定时炸弹”——这时候不能只想着关掉自增长或删数据，得把部分数据文件物理迁移到有空闲空间的磁盘上。
怎么确认是磁盘满而非表空间逻辑满
先排除误判：ORA-01653 报错时，很多人直接冲去加数据文件，结果发现 df -h 显示数据文件所在挂载点使用率 100%，而表空间里还有空闲块（dba_free_space 非空）。这就是典型的“磁盘物理满”，不是“表空间逻辑满”。
- 查磁盘：在操作系统执行
df -h /u01/app/oracle/oradata（路径替换成你实际的数据文件目录） - 查数据文件位置：
SELECT file_name, bytes/1024/1024/1024 "GB", autoextensible FROM dba_data_files WHERE tablespace_name = 'USERS'; - 关键信号：如果某几个
file_name路径都落在同一个快被写爆的磁盘上，且autoextensible = 'YES'，那迁移就刻不容缓
迁移前必须停掉自动扩展并锁定文件大小
迁移过程中若文件还在动态增长，cp 或 rsync 会失败或产生不一致。必须先冻结它：
- 执行
ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' AUTOEXTEND OFF; - 再用
RESIZE把当前实际占用空间对齐（避免迁移后浪费）：ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' RESIZE 18G;（数值来自dba_segments+ HWM 计算，不是随便估的） - 切记：别跳过这步。曾有案例因没关
AUTOEXTEND，迁移中途文件被写满，导致数据库报 ORA-01114
移动数据文件的三步实操（在线，无需停库）
Oracle 支持在线移动数据文件，但要求表空间为 ONLINE 状态，且数据库为归档模式（生产环境基本都满足）：
- 第一步：把文件 offline：
ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' OFFLINE; - 第二步：操作系统层复制（非 mv！）到新磁盘：
cp /u01/app/oracle/oradata/ORCL/users01.dbf /u02/app/oracle/oradata/ORCL/users01_moved.dbf（/u02是有空间的新挂载点） - 第三步：在数据库内切换路径：
ALTER DATABASE RENAME FILE '/u01/app/oracle/oradata/ORCL/users01.dbf' TO '/u02/app/oracle/oradata/ORCL/users01_moved.dbf';，然后 online：RECOVER DATAFILE '/u02/app/oracle/oradata/ORCL/users01_moved.dbf';→ALTER DATABASE DATAFILE '/u02/app/oracle/oradata/ORCL/users01_moved.dbf' ONLINE;
迁移后别忘了清理和验证
旧文件不能直接 rm，得等数据库彻底释放锁；同时要检查是否真腾出了空间：
- 确认新路径生效：
SELECT file_name, status FROM dba_data_files WHERE file_name LIKE '%moved%';应返回ONLINE - 检查旧路径文件是否无进程占用：
lsof | grep users01.dbf，无输出才可安全删除 - 立刻重开自增长（但改用新路径）：
ALTER DATABASE DATAFILE '/u02/app/oracle/oradata/ORCL/users01_moved.dbf' AUTOEXTEND ON NEXT 500M MAXSIZE 32767M; - 最后验证：插入测试数据，观察是否走新文件、磁盘空间是否真正释放
最易忽略的是迁移后未更新备份脚本里的路径，或忘记在 RMAN 中 CATALOG 新文件——下次恢复时才发现备份集指向的还是旧路径。
