创建BIGFILE表空间需显式指定BIGFILE关键字，且仅允许一个DATAFILE；必须启用本地管理，不支持字典管理；适用于OLAP、归档等少文件大容量场景，但不支持ADD DATAFILE及在线收缩。
创建 BIGFILE 表空间的正确语法和必要条件
oracle 中 bigfile 表空间不是默认选项，必须显式指定，否则即使只建一个数据文件，也仍是 smallfile 类型。关键在于 create tablespace ... bigfile 这个关键词顺序不能颠倒，且必须配合单个数据文件（不能在语句里写多个 datafile）。
常见错误现象：ORA-01972: must specify a datafile name 或建完后查 DBA_TABLESPACES.BIGFILE 字段是 NO——说明语法没生效。
-
BIGFILE必须放在TABLESPACE名称之后、DATAFILE之前，例如：CREATE BIGFILE TABLESPACE tbs_big DATAFILE '/u01/oradata/db/tbs_big01.dbf' SIZE 1G; - 只能指定一个
DATAFILE，多写会报错：ORA-30974: invalid option for BIGFILE tablespace - 数据库必须启用
EXTENT MANAGEMENT LOCAL（10g+ 默认满足），不支持字典管理 - 若使用 OMF（Oracle Managed Files），
DB_CREATE_FILE_DEST需已设置，否则需写绝对路径
BIGFILE 表空间的真实优势：不是“更大”，而是“更少”
很多人以为 BIGFILE 是为了突破 32GB 单文件限制——其实从 Oracle 10g 起，SMALLFILE 表空间单文件上限已是 32TB（取决于 DB_BLOCK_SIZE 和 MAXEXTENTS）。真正优势是减少数据字典压力和管理开销。
典型使用场景：OLAP 数据库、归档表空间、大型索引区——这些地方常需要几十甚至上百 GB 的连续空间，但不需要频繁增删文件。
- 每个
BIGFILE表空间在DBA_DATA_FILES中只占一行，而同等容量的SMALLFILE可能要拆成几十个文件，拖慢字典查询 - 自动段空间管理（ASSM）下，
BIGFILE的位图块分布更集中，高并发插入时争用略低 - 备份恢复工具（如 RMAN）对单大文件的处理效率未必更高，但脚本逻辑更简单——毕竟不用循环处理几十个
DATAFILE
BIGFILE 表空间的硬性限制和兼容性风险
它不是万能方案，几个关键限制直接决定你能不能用、敢不敢用。
最容易踩的坑：误以为迁移方便，结果发现没法在线收缩——BIGFILE 不支持 RESIZE 到小于当前已用空间，也不支持 SHRINK SPACE（连 ALTER DATABASE DATAFILE ... RESIZE 都受限于底层文件系统是否支持“打洞”）。
- 最大文件大小取决于
DB_BLOCK_SIZE：DB_BLOCK_SIZE=8K时理论极限约 32TB；32K时可达 128TB——但实际受操作系统单文件上限制约（如 ext4 默认 16TB） - 不支持
ALTER TABLESPACE ... ADD DATAFILE，扩容只能靠RESIZE原有文件，一旦磁盘满，无路可退 - RAC 环境下，所有节点必须能访问同一存储路径，且文件系统需支持并发写（如 OCFS2、ASM、NFSv4.1+）；普通 NFS 可能引发 I/O 锁等待
- Oracle 11gR2 之前版本，
BIGFILE表空间无法作为默认临时表空间（DEF_TEMP_TABLESPACE）
什么时候该坚持用 SMALLFILE，而不是强行上 BIGFILE
别被“大文件”名字带偏——它解决的是管理粒度问题，不是容量瓶颈。很多团队盲目切换后反而增加运维复杂度。
典型反模式：把用户表空间全换成 BIGFILE，结果每天要手动 RESIZE 几十次，或者因一次误操作填满整个 10TB 文件导致业务阻塞。
- 需要频繁增删数据文件的场景（如按月分区的交易库），
SMALLFILE更灵活 - 备份策略依赖文件级快照（如 ZFS、NetApp）——
BIGFILE会让快照体积暴增且恢复粒度变粗 - 使用 Data Guard 且备库为文件系统存储时，
BIGFILE同步延迟可能更高（网络传输大块连续数据更敏感） - DBA 团队不熟悉
DBMS_SPACE或V$TEMP_SPACE_HEADER等定位真实空闲空间的视图，容易误判容量
真正关键的判断点从来不是“能不能建”，而是“扩容节奏是否可控”和“DBA 是否愿意为单点故障多担一份责任”。
