Oracle 11g表空间不足时，RESIZE失败主因是单数据文件达物理上限（如8K块=32GB），需查dba_data_files确认size_mb是否接近maxsize_mb；优先添加新数据文件而非硬扩旧文件；temp表空间需单独处理，且须设MAXSIZE。
oracle 11g 表空间不足时，直接 resize 现有数据文件是最快速的解法——但前提是该文件还没撞上 32gb（或更低）的物理上限。
为什么 RESIZE 有时会失败？
执行 ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE 4000M 报错 ORA-01237: cannot extend datafile，大概率不是磁盘没空间，而是文件已达 Oracle 11g 单文件容量硬限制。这个上限由建库时的 DB_BLOCK_SIZE 决定：
– 若 DB_BLOCK_SIZE = 8K，理论最大为 32GB（4194304 × 8K）；
– 若是 4K，则只有 16GB。
你查 dba_data_files.bytes 得到的当前大小，很可能已无限接近这个天花板。
怎么确认是否触顶？
运行这条 SQL 获取关键信息：
SELECT tablespace_name, file_name, bytes/1024/1024 AS size_mb,
maxbytes/1024/1024 AS maxsize_mb, autoextensible
FROM dba_data_files
WHERE tablespace_name = 'YOUR_TABLESPACE_NAME';
重点看三列：
– size_mb 接近 maxsize_mb（比如 32767 vs 32768）→ 已无法再 RESIZE；
– autoextensible = 'NO' 且 maxsize_mb 明显偏小 → 说明当初建库用的是小 DB_BLOCK_SIZE，扩容必须换思路；
– autoextensible = 'YES' 但 maxsize_mb 被设死（如 2048）→ 只需改 MAXSIZE 即可，不用加文件。
加新数据文件比硬扩旧文件更稳妥
只要磁盘路径有空间、表空间状态是 ONLINE，添加新文件几乎无风险，且绕过单文件限制。典型操作：
ALTER TABLESPACE users ADD DATAFILE '/u01/oradata/orcl/users02.dbf' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 10240M;- 文件名别用纯数字后缀（如
users01.dbf→users02.dbf），避免和 RMAN 备份命名冲突； - 路径必须是数据库所在主机真实存在的、Oracle 进程有写权限的目录，不能是 NFS 挂载点（除非明确配置支持）；
- 如果原表空间含多个文件，Oracle 会自动做 extent 分配均衡，无需手动干预。
临时表空间不足要单独处理
普通表空间不够影响 DML，而 temp 不足会导致排序、哈希连接直接报 ORA-01652: unable to extend temp segment。它不走 DATAFILE 扩容逻辑：
- 扩已有临时文件：
ALTER DATABASE TEMPFILE '/u01/oradata/orcl/temp01.dbf' RESIZE 2048M; - 加新临时文件：
ALTER TABLESPACE temp ADD TEMPFILE '/u01/oradata/orcl/temp02.dbf' SIZE 1024M AUTOEXTEND ON; -
temp表空间不支持MAXSIZE UNLIMITED，必须显式指定上限，否则可能耗尽磁盘。
真正麻烦的不是“怎么加”，而是加完之后没人清理历史大对象或归档日志——空间很快又满。每次扩容前，先跑一遍 dba_segments 查最大的几个段，比盲目加文件更有长期价值。
