Bigfile表空间只能通过RESIZE或AUTOEXTEND调整唯一数据文件大小，不支持ADD DATAFILE；ORA-32773报错说明表空间实为smallfile，因建库时未正确指定CREATE BIGFILE TABLESPACE语法。
bigfile 表空间不能靠“加文件”扩容，只能用 resize 或 autoextend 调整那个唯一数据文件的大小——这是它和 smallfile 的根本区别，不是操作遗漏，是设计强制。
为什么 ALTER TABLESPACE ... RESIZE 会报 ORA-32773？
因为这个语法只对 BIGFILE 表空间有效；SMALLFILE 表空间不支持。但很多人建完表空间没确认类型，一执行就报错：
-
ORA-32773: operation not supported for smallfile tablespace USERS—— 说明你查的DBA_TABLESPACES.BIGFILE是NO，当前表空间根本不是 BIGFILE - 常见原因：建表空间时漏写
BIGFILE关键字，或写错位置（必须是CREATE BIGFILE TABLESPACE，不能是CREATE TABLESPACE BIGFILE） - 验证命令：
SELECT tablespace_name, bigfile FROM dba_tablespaces WHERE tablespace_name = 'TBS_BIG';，结果必须是YES
ALTER DATABASE DATAFILE ... RESIZE 扩容时的硬限制
这是 BIGFILE 唯一合法的扩容路径，但容易卡在几个边界上：
-
RESIZE目标值不能小于当前已用空间（dba_segments.bytes总和），否则报ORA-03297：文件包含超出请求长度的使用数据 -
MAXSIZE要提前设好，否则AUTOEXTEND ON可能撞到文件系统上限（如 ext4 默认 16TB），直接触发ORA-01144 - 裸设备或 ASM 磁盘组需额外检查剩余空间：
SELECT name, total_mb, free_mb FROM v$asm_diskgroup;，ASM 不会实时同步MAXSIZE检查 - 示例安全扩容：
ALTER DATABASE DATAFILE '/u01/oradata/ORCL/tbs_big.dbf' RESIZE 120G;
RMAN 备份与恢复中 RESIZE 引发的隐性风险
文件越大，RMAN 处理越“重”，不是性能问题，而是流程约束变紧：
- 一个 BIGFILE = 一个 BACKUP PIECE（除非显式配置
MAXPIECESIZE），备份片体积动辄上百 GB，网络或磁盘 IO 容易打满 - 恢复时不能跳过空闲块，
RESTORE DATAFILE必须读完整个文件头+所有分配块，比 SMALLFILE 恢复慢 2–5 倍（实测 100GB 文件 vs 10×10GB 文件） -
RECOVER DATABASE UNTIL TIME可能在 BIGFILE 上失败，因 SCN 分布跨全文件，部分块未归档；此时必须改用RECOVER DATAFILE 1（BIGFILE 的FILE_ID永远是 1） - 别依赖
MAXSIZE UNLIMITED：文件系统 inode 耗尽、ASM 磁盘组空间检查延迟，都可能让自动扩展在最后一刻失败
迁移现有 SMALLFILE 表空间到 BIGFILE 的真实成本
没有在线转换命令，ALTER TABLESPACE ... CONVERT TO BIGFILE 是伪指令，仅用于新建空表空间：
- 真实路径只有两条：逻辑导出/导入（
expdp/impdp），或跨平台传输表空间（TTS），两者都要求停机 - 停机时间取决于数据量和网络带宽，1TB 数据在万兆网下通常要 2–4 小时，期间业务中断
- 迁移后原 SMALLFILE 文件不能直接删，必须等确认新表空间数据一致、应用无异常后再清理，否则无法回退
- 特别注意索引和 LOB 段：它们可能分散在多个 SMALLFILE 中，导入时若未指定
TABLESPACE，会落到默认表空间，导致跨表空间引用
真正难的不是执行 RESIZE，而是判断该不该用 BIGFILE——它省的是 DBA 的维护脚本行数，不是磁盘 IO 或恢复时间。一旦选错场景，扩容操作本身就会变成故障入口。
