关键看最大连续空闲块：执行SELECT tablespace_name, MAX(bytes) FROM dba_free_space确认，若小于段的next_extent或表空间default_next_extent，将报ORA-01653/01654；LMT下next_extent常被忽略，但错误仍由最大连续空闲块决定。
查 DBA_EXTENTS 看当前最大连续空闲块
Oracle 表段（如表、索引）在插入或更新时，若当前数据块不够，会向所在表空间申请下一个 extent。这个 extent 必须是**连续的空闲空间**，大小由段的 next_extent 或表空间的默认存储参数决定。但真正能分到多大的连续块，取决于 DBA_FREE_SPACE 中记录的“最大可用连续空闲区”（MAX(bytes)），不是总空闲和平均值。
所以关键不是“还剩多少 MB”，而是“最大的一块空闲空间有多大”。执行：
SELECT tablespace_name, MAX(bytes) AS max_free_bytes FROM dba_free_space WHERE tablespace_name = 'YOUR_TABLESPACE_NAME' GROUP BY tablespace_name;
如果返回值小于你段的 next_extent（或默认 INITIAL + NEXT），就会报 ORA-01653（表无法扩展）或 ORA-01654（索引无法扩展）。
确认段自身的 NEXT 值从哪来
段的下一次扩展大小不一定是硬编码的。它优先取自段自己的存储参数， fallback 到表空间的默认设置：
- 用
SELECT segment_name, segment_type, next_extent FROM dba_segments WHERE segment_name = 'YOUR_SEG_NAME' AND owner = 'OWNER_NAME';查段级next_extent - 若为
NULL，说明该段使用了表空间的默认NEXT—— 查SELECT default_next_extent FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TABLESPACE_NAME'; - 注意：本地管理表空间（LMT）下，
next_extent通常被忽略，实际分配由区大小（uniform 或 autoallocate）控制；但错误仍由“最大连续空闲块
判断是否真缺连续空间，而非总空间不足
常见误判：看到 DBA_FREE_SPACE 总空闲有 5GB，就认为够用；结果扩容失败。这是因为碎片化严重，最大连续块只有 20MB，而段要申请 64MB 的 extent。
验证方法：
- 运行上面的
MAX(bytes)查询，换算成 MB：ROUND(MAX(bytes)/1024/1024, 2) - 对比你段实际需要的 extent 大小（见上一节）
- 若前者 ALTER TABLE ... MOVE 或
SHRINK SPACE COMPACT整理碎片（前提：段支持且有足够空闲）
ORA-01653 报错时最该先查什么
收到这个错误，别急着加文件。按顺序快速检查：
- 查
dba_free_space的MAX(bytes)—— 是否真的小于段所需 extent？ - 查对应 datafile 是否
AUTOEXTEND ON且MAXSIZE未达上限？执行：SELECT file_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name = '...'; - 查磁盘物理空间：
df -h对应挂载点 —— 即使 DBA 觉得还能扩，OS 层可能已满 - 如果是 RAC 环境，确认所有节点都能访问该 datafile 路径（尤其 ASM 别名路径是否一致）
连续空间不足比总空间不足更隐蔽，也更难自动修复——脚本可以加文件，但没法一键 defrag。每次看到 MAX(bytes) 明显偏小，就得人工介入评估是否需要 move/shrink 或调整区管理策略。
