先查DBA_FREE_SPACE，重点看最大连续空闲块（MAX(bytes)），而非总空闲空间；因ORA-01654本质是无法找到足够大的连续extent，即使表空间总剩余空间充足，若最大连续块小于索引NEXT_EXTENT值即会报错。
ORA-01654报错时，先查DBA_FREE_SPACE还是DBA_DATA_FILES？
直接查DBA_FREE_SPACE——但别只看“总空闲”，得看“最大连续空闲块”。ORA-01654本质是找不到足够大的连续extent，不是总空间不够。比如表空间剩400MB，但NEXT_EXTENT要700MB，照样报错。
执行这条SQL确认关键指标：
SELECT tablespace_name,
ROUND(SUM(bytes)/1024/1024) "free_MB",
ROUND(MAX(bytes)/1024/1024) "max_chunk_MB"
FROM dba_free_space
WHERE tablespace_name = 'YOUR_TABLESPACE_NAME'
GROUP BY tablespace_name;
如果max_chunk_MB明显小于索引的NEXT_EXTENT（可从DBA_INDEXES.NEXT_EXTENT查），问题就定位了。
为什么ALTER DATABASE DATAFILE ... RESIZE有时会失败？
Oracle 11g单个数据文件有硬上限：32GB（默认8KB block size）。如果当前文件已是32GB，RESIZE会直接报错，不是语法或权限问题。
- 用
SELECT file_name, bytes/1024/1024/1024 GB FROM dba_data_files WHERE tablespace_name = 'YOUR_TS';确认是否已达32GB - 已达上限时，必须走
ALTER TABLESPACE ... ADD DATAFILE，不能只靠RESIZE -
ADD DATAFILE路径需确保Oracle进程有写权限，且磁盘剩余空间充足（不止是数据库层面）
NEXT_EXTENT设得过大是常见设计缺陷
很多老脚本或迁移工具会沿用过时的storage参数，比如NEXT 2G PCTINCREASE 50。在11g中，这会导致下一次扩展需要3G连续空间，极难满足。
修复方式不是临时扩容，而是重建索引并固化合理参数：
ALTER INDEX your_index_name REBUILD TABLESPACE your_ts STORAGE (INITIAL 256K NEXT 256K PCTINCREASE 0);
要点：
-
NEXT值建议设为256K–1M，避免过大；PCTINCREASE必须为0（11g已不推荐动态增长） - 重建前确认目标表空间有足够初始空间（
INITIAL大小要能落地） - 重建期间索引不可用，生产环境需安排窗口
自动扩展（AUTOEXTEND）开不开？怎么开才安全？
可以开，但必须配MAXSIZE。11g默认不限制MAXSIZE等于允许无限增长，可能撑爆文件系统。
正确做法：
- 先查当前是否已启用：
SELECT file_name, autoextensible, maxbytes/1024/1024/1024 MAX_GB FROM dba_data_files; - 启用时明确上限：
ALTER DATABASE DATAFILE '/path/to/file.dbf' AUTOEXTEND ON NEXT 128M MAXSIZE 30G; - 多个数据文件更稳妥：分散I/O压力，也避免单文件触顶
真正容易被忽略的是MAXSIZE没设——它不会报错，但某天磁盘写满后所有DML都会卡死，比ORA-01654更难排查。
