BIGFILE表空间不是“更大更快”的默认选项，而是专为单文件长期超100GB、且能接受恢复慢、备份片大、无法在线收缩等代价的场景设计的简化管理手段；创建必须显式写CREATE BIGFILE TABLESPACE，漏掉BIGFILE关键字就仍是SMALLFILE，后续扩容操作均会报错。
直接说结论：在 Oracle 19c 中，BIGFILE 表空间不是“更大更快”的默认选项，而是专为单文件长期超 100GB、且能接受恢复慢、备份片大、无法在线收缩等代价的场景设计的简化管理手段；创建必须显式写 CREATE BIGFILE TABLESPACE，漏掉 BIGFILE 关键字就还是 SMALLFILE，后续所有扩容操作都会报错。
CREATE BIGFILE TABLESPACE 语法不能颠倒或省略
Oracle 不会根据文件大小自动识别 Bigfile —— 即使你建一个 200GB 的表空间，没写 BIGFILE，它就是 SMALLFILE 类型，查 DBA_TABLESPACES.BIGFILE 返回 NO，后续 ALTER TABLESPACE ... RESIZE 直接报 ORA-32773。
正确写法只有一种：BIGFILE 必须紧接 CREATE 之后、TABLESPACE 之前：
CREATE BIGFILE TABLESPACE tbs_big DATAFILE '/u01/oradata/db/tbs_big.dbf' SIZE 64G AUTOEXTEND ON NEXT 4G MAXSIZE 200G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
常见错误包括：
-
CREATE TABLESPACE tbs_big BIGFILE ...→ 报ORA-01972或静默失败 -
CREATE BIGFILE TABLESPACE tbs_big DATAFILE 'f1.dbf', 'f2.dbf'→ 报ORA-30974（Bigfile 只允许一个DATAFILE） - 省略
EXTENT MANAGEMENT LOCAL或SEGMENT SPACE MANAGEMENT AUTO→ 可能初始化失败或报ORA-01644/ORA-03242
扩容只能动那个唯一 DATAFILE，别试 ADD DATAFILE
BIGFILE 表空间在 DBA_DATA_FILES 中永远只有 1 行，FILE_ID 恒为 1。它的扩容逻辑和 SMALLFILE 完全不同：不支持 ADD DATAFILE，也不支持在线收缩，所有空间调整都必须指向那个物理文件路径。
推荐用明确路径的语句，避免歧义：
- ✅ 安全：
ALTER DATABASE DATAFILE '/u01/oradata/db/tbs_big.dbf' RESIZE 150G - ✅ 有效（仅对 Bigfile）：
ALTER TABLESPACE tbs_big RESIZE 150G - ❌ 报
ORA-32771：ALTER TABLESPACE tbs_big ADD DATAFILE ...
注意：RESIZE 值不能小于当前已用空间（查 DBA_SEGMENTS 中该表空间下所有 BYTES 总和），否则报 ORA-03297；MAXSIZE 也不能超过 OS 单文件上限（如 ext4 默认 16TB），否则建表空间时就卡在 ORA-01144。
RMAN 备份与恢复的隐性代价常被低估
Bigfile 让 RMAN 脚本变简单（不用循环处理几十个文件），但物理代价显著：
- 备份片（
backup piece）体积暴涨：LIST BACKUP OF TABLESPACE tbs_big通常只输出 1 个PIECE，但大小可能达数百 GB —— 网络传输、介质校验时间陡增 - 全量恢复更慢：
RESTORE DATAFILE 1必须读完整个文件头 + 所有已分配块，实测比同等容量的 10×10GBSMALLFILE慢 2–5 倍 -
RECOVER DATABASE UNTIL TIME容易失败：因 SCN 分布跨全文件，部分块未归档；此时必须改用RECOVER DATAFILE 1 - 若需拆分备份片，得提前配置：
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 50G
旧版 RMAN（如 10g 早期补丁集）或未适配大文件的备份工具，在恢复阶段才暴露 ORA-01274，不是建库时报错，容易漏测。
OLTP 场景下慎设为 DEFAULT TABLESPACE
执行 ALTER DATABASE DEFAULT TABLESPACE tbs_big 后，所有未显式指定表空间的用户、临时段、甚至部分 Oracle 内部对象都会挤进这个单文件 —— 这不是简化，是集中风险点。
尤其在 OLTP 系统中，这会放大以下问题：
- 闪回日志压力集中，
DB_RECOVERY_FILE_DEST空间突增 - Checkpoint 和 DBWR 压力集中在单个文件上，IO 瓶颈更明显
- 无法按业务模块隔离故障域：一个文件损坏，整个默认表空间不可用
- 备份窗口拉长，增量备份生成的归档压力也更难预测
真正需要 BIGFILE 的时刻很窄：你确认单个文件要长期维持在 100GB 以上，且愿意用“恢复慢、备份片大、无法收缩”换“少管一个文件”。其他情况，老老实实用 SMALLFILE + 合理规划文件数量更稳妥。
