最大连续空闲块大小决定对象扩容能力，需查DBA_FREE_SPACE中MAX(bytes)；总空闲空间不等于可用连续空间，碎片化会导致ORA-01652错误。
查 DBA_FREE_SPACE 中的最大连续块（MAX(bytes)）
oracle 不直接暴露“剩余空间总量”，而是按“空闲 extent”分散记录在 dba_free_space 视图里。真正影响对象扩容（比如建大表、索引）的是**最大连续空闲块大小**，不是总空闲和。执行以下语句可查每个表空间当前最大的单块空闲空间（单位 mb）：
SELECT tablespace_name,
ROUND(MAX(bytes) / 1024 / 1024, 2) AS max_free_chunk_mb,
COUNT(*) AS free_extents_count,
ROUND(SUM(bytes) / 1024 / 1024, 2) AS total_free_mb
FROM dba_free_space
GROUP BY tablespace_name
ORDER BY max_free_chunk_mb;
注意：MAX(bytes) 是关键——如果某表空间 total_free_mb 很大但 max_free_chunk_mb 只有 8，而你要建一个需要 64MB 连续空间的索引，就会报 ORA-01652: unable to extend temp segment 类错误。
为什么不能只看 DBA_DATA_FILES 和 DBA_FREE_SPACE 的 SUM？
因为碎片化问题：总空闲空间 ≠ 可用连续空间。常见误区是用 SUM(bytes) 算出 “还剩 5GB”，结果 CREATE INDEX 失败。原因包括：
-
DBA_FREE_SPACE中每条记录是一个 extent，可能被多次分配/释放后变得零散 - 自动段管理（ASSM）下，位图块会合并小空闲块，但仍有上限（如 1MB、8MB、64MB 等区大小）
- 即使表空间启用了
AUTOEXTEND，新扩展出的空间也未必能拼接成大连续块
所以必须查 MAX(bytes)，尤其在做大批量导入、重建索引或分区操作前。
如何快速判断是否要加数据文件或整理碎片？
对比两个值即可决策：
- 若
max_free_chunk_mb 且你即将执行需大连续空间的操作（如 <code>ALTER TABLE ... MOVE、CREATE INDEX ... ONLINE），优先考虑新增数据文件（比COALESCE更快） - 对非关键表空间，可尝试
ALTER TABLESPACE xxx COALESCE;合并相邻空闲 extent（仅对字典管理表空间有效；ASSM 表空间该命令基本无效） - 临时表空间不用查
DBA_FREE_SPACE，它不走这个视图，应查V$TEMP_SPACE_HEADER或V$SORT_SEGMENT
加文件前务必确认磁盘空间足够，并检查原数据文件是否已 AUTOEXTEND ON ——否则新加的文件也可能很快写满。
容易被忽略的权限与过滤条件
执行上述查询需具备 SELECT_CATALOG_ROLE 或直接授予 SELECT on DBA_FREE_SPACE 和 DBA_DATA_FILES。另外注意：
-
DBA_FREE_SPACE不包含临时表空间信息，临时空间请查DBA_TEMP_FILES+V$TEMP_EXTENT_POOL - 如果查询结果为空，先确认是否连接的是
SYS或有 DBA 权限的用户；普通用户只能查USER_FREE_SPACE（仅自己默认表空间） - 某些 OEM 或监控脚本会误把
DBA_SEGMENTS.bytes当已用空间，但实际高水位线（HWM）以上可能有大量未格式化的空闲块，DBA_FREE_SPACE才是真实可用连续空间来源
碎片不报警，但会在最忙的时候突然卡住 DDL —— 所以别等报错才查 MAX(bytes)。
