Bigfile表空间单文件设计由ROWID寻址机制决定：其32位块号取代SMALLFILE的22位块号，取消文件号编码，故仅支持单一数据文件，添加第二个文件会触发ORA-32771硬限制。
Bigfile表空间的“单文件”设计是ROWID寻址机制决定的
Oracle 10g 引入 BIGFILE 表空间，根本原因不是为了简化管理，而是为突破传统 SMALLFILE 数据文件的物理地址空间限制。关键在 ROWID 编码方式：SMALLFILE 的 ROWID 用 22 位表示数据块号（block#），最多支持 2^22 − 1 = 4,194,303 个块；而 BIGFILE 改用 32 位表示块号，上限跃升至 2^32 − 1 ≈ 4G 块。但这个扩展必须绑定到「单一文件」——因为 ROWID 中不再编码文件号（file#），只保留相对块号（block#）和行号（row#）。一旦允许多个文件，就无法唯一定位物理位置。
你不能对 bigfile 表空间执行 ADD DATAFILE，会直接报错
尝试向已存在的 BIGFILE 表空间添加第二个数据文件时，Oracle 不会提示“不推荐”，而是明确拒绝：
SQL> ALTER TABLESPACE users ADD DATAFILE '/u01/oradata/db/users02.dbf' SIZE 100M; ERROR at line 1: ORA-32771: cannot add file to bigfile tablespace
这不是权限或语法问题，是内核级硬限制。同理，RESIZE 操作针对的是整个表空间（即那个唯一的数据文件），所以语法是 ALTER TABLESPACE ... RESIZE，而不是 ALTER DATABASE DATAFILE ... RESIZE —— 后者才是 SMALLFILE 的操作路径。
bigfile 和 smallfile 表空间可以共存，但混用要小心兼容性
一个数据库里完全可以同时存在 BIGFILE 和 SMALLFILE 表空间，DBA_TABLESPACES 视图里的 BIGFILE 列就是判断依据。但要注意：
-
BIGFILE表空间强制要求本地区管理（EXTENT MANAGEMENT LOCAL），不支持字典管理（DICTIONARY） -
BIGFILE表空间的段空间管理必须是AUTO（除UNDO和TEMPORARY类型外） - 备份恢复工具、Data Pump 导出导入、甚至某些第三方监控脚本，若未适配
BIGFILE特性，可能误判文件数或大小
真正容易被忽略的点：操作系统文件系统限制仍在起作用
即便 Oracle 允许单个 BIGFILE 达到 32TB（8K 块），实际能否创建成功，还取决于底层文件系统。例如：
- FAT32 单文件上限 4GB，根本无法创建任何大于此的
BIGFILE - ext3 默认单文件上限 2TB，需启用
large_file特性 - NTFS（Windows）理论支持 16EB，但 Oracle 进程是否能 mmap 超大文件，还受 OS 内存映射机制影响
所以看到 ORA-01144: 文件大小 (4194304 块) 超出 4194303 块的最大数 报错时，别急着改 Oracle 参数——先查 df -T 或 fsutil fsinfo ntfsinfo 确认文件系统能力。
