oracle smallfile单数据文件上限为4194303块（约32gb），源于rowid中22位block number编码限制；超限报ora-03206；安全maxsize应设32767m；扩容应增文件而非调参，加完须执行coalesce防碎片。
不是“只能扩展到32GB”，而是默认 db_block_size=8192 时，单个 SMALLFILE 数据文件最多容纳 4194303 个块，算下来约 32GB —— 这是 Oracle 的 rowid 编码硬限制，改不了。
ORA-03206 或 ORA-01144 报错直接暴露了这个限制
当你执行 ALTER TABLESPACE ... ADD DATAFILE ... MAXSIZE 32G 却报 ORA-03206: maximum file size of (4194304) blocks in AUTOEXTEND clause is out of range，说明你设的值刚好踩在边界上：Oracle 允许的最大块数是 2^22 - 1 = 4194303，而 32GB ÷ 8KB = 4194304 块，超了 1 块。
- 别用 “32G” 这种模糊单位，
MAXSIZE 32767M才安全（8192 × 4194303 ÷ 1024 ÷ 1024 ≈ 32767.999） - 图形化工具或脚本里写
32G，Oracle 内部会转成字节再除以块大小，极易越界 - 查当前块大小必须用：
SELECT value FROM v$parameter WHERE name = 'db_block_size'，不能猜
为什么是 22 位？和 rowid 强绑定
Oracle 每行数据的物理地址由 rowid 标识，其中 block number 字段只占 22 位。这意味着一个数据文件最多编址 2^22 = 4194304 个块，但第 0 块被保留作内部用途，实际可用上限就是 4194303 块。
- 这个设计从 Oracle 8i 沿用至今，所有版本、所有平台都一样
- 哪怕你用 XFS（支持 500TB 单文件）或 ASM（支持 64TB 文件），SMALLFILE 表空间仍卡死在这个值
-
db_block_size是建库时定死的，之后无法修改 —— 所以扩容不是调参数，而是换策略
Bigfile 能破 32GB，但代价是管理逻辑全变
BIGFILE 表空间把 block number 扩到 32 位，单文件上限升到 2^32 - 1 块（8KB 块下≈32TB），但它只允许一个数据文件，且和传统运维习惯冲突：
-
ALTER TABLE ... MOVE TABLESPACE会锁表，OLTP 系统扛不住 - RMAN 备份恢复变慢：单文件大了，增量窗口拉长，出问题时恢复时间指数增长
- 磁盘 I/O 集中在一个 LUN 上，容易触发存储队列延迟，监控脚本也常不兼容
- 它适合新建数仓、归档库等场景，不适合已有 OLTP 生产库在线扩容
加 datafile 才是日常最稳的解法
Oracle 官方文档明确推荐用增加多个 SMALLFILE 数据文件来扩容，核心就三点：分散、可控、可逆。
- 路径必须绝对路径且 Oracle 用户有写权限，比如
'/u01/oradata/PROD/users02.dbf' -
SIZE别设太小（至少 1GB），否则频繁 autoextend 触发 IO 毛刺 -
NEXT要匹配业务节奏：OLTP 建议 512M，批量导入可设 2G，但别超磁盘剩余连续空间的 70% - 加完立刻执行
ALTER TABLESPACE USERS COALESCE，否则碎片会导致ORA-01653（空闲总量够却扩不了）
真正容易被忽略的，是很多人加完 datafile 就以为万事大吉，其实没做 COALESCE，表空间碎片还在，下次插入照样报错 —— 这个动作不耗时，但必须手动触发。
