判断Oracle表空间碎片需综合三指标：DBA_FREE_SPACE行数超200表明明显碎片，MIN(BYTES)极小而MAX(BYTES)极大说明空闲块不均衡，HWM悬空与行迁移加剧表级碎片，且DBA_SEGMENT_ADVISOR_RESULTS视图不存在。
查 DBA_FREE_SPACE 中空闲区数量和大小分布
碎片严重与否，不看总空闲量，而看空闲区（extent）是否又小又碎。关键指标是 DBA_FREE_SPACE 的行数和 BYTES 分布。
-
COUNT(*)超过 200 行，基本可判定存在明显碎片；超过 500 行，通常需干预 -
MIN(BYTES)接近几 KB（如 8192 或 65536），MAX(BYTES)却达几百 MB，说明空闲块极不均衡 - 若
FREE_EXTENTS远大于TOTAL_FREE_MB / AVG_MB的理论值（即总空闲 ÷ 平均单块大小），说明大量小块堆积 - 必须用 DBA 权限执行；普通用户查
USER_FREE_SPACE仅返回默认表空间的有限记录
执行示例：
SELECT TABLESPACE_NAME, ROUND(SUM(BYTES)/1024/1024, 2) AS "FREE_MB", COUNT(*) AS "FREE_EXTENTS", ROUND(MIN(BYTES)/1024/1024, 2) AS "MIN_MB", ROUND(MAX(BYTES)/1024/1024, 2) AS "MAX_MB", ROUND(AVG(BYTES)/1024/1024, 2) AS "AVG_MB" FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME ORDER BY FREE_MB DESC;
确认最大连续空闲块是否小于操作需求
ORA-01652 / ORA-01658 报错的直接原因是请求的 extent 大小 > 当前最大连续空闲块，不是总空间不够。
- 建表或索引时指定
STORAGE(INITIAL 64M)，但MAX(BYTES)只有 8MB，必然失败 - 批量导入、在线重建索引、分区 split 等操作对连续空间更敏感，需提前验证
- ASSM 表空间中，即使启用了
AUTOEXTEND，新扩展的空间也不自动拼接进现有碎片间隙
快速检查语句：
SELECT tablespace_name, ROUND(MAX(bytes) / 1024 / 1024, 2) AS "MAX_FREE_MB", COUNT(*) AS "FREE_EXTENTS_COUNT" FROM dba_free_space GROUP BY tablespace_name ORDER BY "MAX_FREE_MB";
交叉验证高水位线与实际数据占用比
表级碎片常被忽略，但它直接影响全表扫描性能和物理 I/O 效率。重点看 BLOCKS 和 NUM_ROWS × AVG_ROW_LEN 的偏差。
- 先确保统计信息最新：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA', tabname => 'TABLE_NAME'); - 若
blocks * 8192（单位字节）远大于num_rows * avg_row_len，说明 HWM 悬空，空间未回收 - 常见于频繁 DELETE 后未 SHRINK 的大表；
CHAIN_CNT > 0则进一步表明存在行迁移/链接，加剧碎片影响
简易评估（单位 MB）：
SELECT table_name, ROUND(blocks * 8 / 1024, 2) AS "HWM_MB", ROUND((num_rows * avg_row_len) / 1024 / 1024, 2) AS "DATA_MB", ROUND((blocks * 8 - num_rows * avg_row_len) / 1024 / 1024, 2) AS "WASTE_MB" FROM dba_tables WHERE owner = 'YOUR_SCHEMA' AND blocks > 1000 AND num_rows > 0 ORDER BY "WASTE_MB" DESC;
别信 DBA_SEGMENT_ADVISOR_RESULTS —— 它根本不存在
很多人搜“segment advisor 碎片结果”直接查 DBA_SEGMENT_ADVISOR_RESULTS，结果报 ORA-00942：该视图压根不存在。
- Segment Advisor 结果存于标准顾问视图：
DBA_ADVISOR_TASKS、DBA_ADVISOR_FINDINGS、DBA_ADVISOR_RECOMMENDATIONS - 手动运行后，查
message字段含 “reclaimable space” 或 “shrink” 才算有效建议 - 它对 HWM 悬空敏感，但对
DBA_FREE_SPACE中的小 extent 分散几乎不响应——不能替代基础查询
真正可靠的判断永远来自三组数据交叉：空闲区分布 + 最大连续块 + 表级 HWM 偏差。
