扩容前必须确认的三件事：①目标表空间状态为online而非read only；②新加数据文件路径所在磁盘os层剩余空间充足（df -h验证）；③rac+dg环境下备库对应磁盘组空间足够，否则dg同步中断。
扩容前必须确认的三件事
表空间扩容不是“加完文件就完事”，生产环境里最常踩的坑是：操作完业务依然报 ORA-01654 或 ORA-01653。核心原因往往出在扩容前没确认这三点：
- 目标表空间是否为
READ ONLY状态？查SELECT tablespace_name, status FROM dba_tablespaces，状态必须是ONLINE - 新加的数据文件路径所在磁盘是否有足够剩余空间？仅看数据库内空闲空间不够，
df -h必须同步验证 OS 层磁盘使用率 - 如果是 RAC+DG 环境，备库对应磁盘组是否还有空间？主库扩容后若备库空间不足，DG 同步会中断，
SELECT name, space_used, space_limit FROM v$recovery_file_dest要两边都查
ALTER TABLESPACE ... ADD DATAFILE 的写法陷阱
这条语句写错一个字符就会直接报 ORA-01119，不是语法错误，而是底层文件系统拒绝创建。关键细节必须严格匹配：
- 路径必须用单引号包裹：
'/u01/oradata/ORCL/users02.dbf'，裸写/u01/oradata/ORCL/users02.dbf一定失败 - 大小单位必须大写且带字母：
SIZE 100M可以，SIZE 100m或SIZE 100MB在部分版本会报错 - OMF（Oracle Managed Files）启用时，不能指定路径和文件名，只写
SIZE 100M AUTOEXTEND ON，路径由db_create_file_dest决定 - ASM 环境下路径格式必须是
'+DATA/ORCL/DATAFILE/users02.256.123456789'，不能套用 Linux 文件路径逻辑
自动扩展（AUTOEXTEND）怎么设才安全
AUTOEXTEND ON 不是“开了就高枕无忧”，它只控制单个数据文件的增长行为，不解决表空间整体瓶颈。设得不合理反而引发新问题：
-
NEXT值太小（如NEXT 1M）会导致频繁分配 extent，拖慢大批量插入；太大（如NEXT 2G）可能一次预占大量磁盘却长期不用 -
MAXSIZE必须显式设置，MAXSIZE UNLIMITED在生产环境极危险——磁盘写满后所有 DML 直接挂起 - 建议值：
NEXT 100M MAXSIZE 2G是较稳妥起点，但需结合业务峰值写入量调整；同时必须配合监控脚本定期检查dba_data_files中各文件实际增长情况
扩容后业务仍失败的隐藏原因
执行完 ALTER TABLESPACE users ADD DATAFILE ...，查 dba_free_space 却没看到新增空闲空间？大概率是以下某一种情况：
- 新加文件被创建到了错误表空间（比如把
USERS拼成users，而数据库启用了大小写敏感标识） - 文件创建成功但状态异常，立刻查
SELECT file_name, status, enabled FROM dba_data_files WHERE tablespace_name = 'USERS'，status必须是AVAILABLE - 某些极端场景下（如扩容中途实例崩溃），文件虽存在但未被加入表空间可用列表，此时需手工运行
ALTER DATABASE DATAFILE '/path/file.dbf' ONLINE
真正容易被忽略的是：表空间扩容只是释放了“容器容量”，但已有段（如大表、索引）的 HWM（High Water Mark）不会自动下降。如果业务持续写入老对象，仍可能快速触达瓶颈——这时需要评估是否要 MOVE 表或 REBUILD 索引来回收内部碎片。
