AWR报告无法直接显示表空间碎片率，因其仅记录I/O、等待事件等运行时性能数据，不采集空闲块分布等空间结构信息；评估碎片需借助DBA_FREE_SPACE、DBA_SEGMENTS及FSFI公式等底层手段。
oracle表空间碎片不能靠awr直接看，awr里压根没有表空间碎片指标。它只记录i/o、等待、sql执行等运行时统计，不存空间分配结构数据。真要评估碎片，得绕开awr，用dba_free_space、dba_segments和fsfi公式这类底层视图和计算逻辑。
为什么AWR报告里找不到表空间碎片率
AWR本质是性能快照集合，聚焦“发生了什么”——比如physical reads高不高、db file sequential read等待多不多。它不扫描数据文件的空闲块分布，也不维护每个extent的连续性状态。所以你在“Top Segments by Physical Reads”或“I/O Stats by Tablespace”章节看到的，只是读压力分布，不是碎片本身。误把高物理读等同于高碎片，是新手最常踩的坑。
用FSFI公式快速估算表空间碎片程度
FSFI（Free Space Fragmentation Index）是Oracle官方推荐的表空间碎片粗略指标，值越低碎片越严重。计算逻辑基于空闲区数量、大小和最大连续空闲区，对判断是否需要合并或重建表空间有实际参考价值：
-
FSFI < 30%：碎片严重，大量小空闲区，ALTER TABLESPACE ... COALESCE可能无效，需考虑迁移重建 -
FSFI between 30%–70%：中度碎片，可先尝试COALESCE，再观察后续分配是否仍频繁失败 -
FSFI > 70%：碎片轻微，当前分配效率尚可，暂无需干预
执行语句：
SELECT a.tablespace_name,
SQRT(MAX(a.blocks) / SUM(a.blocks)) * (100 - SQRT(SQRT(COUNT(a.blocks)))) AS fsfi
FROM dba_free_space a, dba_tablespaces b
WHERE a.tablespace_name = b.tablespace_name
AND b.contents NOT IN ('TEMPORARY', 'UNDO')
GROUP BY a.tablespace_name
ORDER BY fsfi;结合AWR中的I/O异常反向佐证碎片影响
虽然AWR不给碎片率，但它能暴露碎片引发的副作用。当表空间碎片严重时，新segment分配容易失败或被迫跨多个不连续extent，导致单次I/O请求变多、延迟上升。这时可在AWR中交叉验证：
- 查“Tablespace IO Stats”章节，确认
Av I/O Elapsed Time是否明显高于其他表空间 - 看“SQL ordered by Physical Reads”，如果某几个SQL反复访问同一表空间下的不同对象，且执行计划含大量
FULL TABLE SCAN，可能是碎片导致缓存效率下降、物理读被迫增加 - 对比两个快照间
physical read IO requests增幅，若远超physical reads增幅，说明每次读取的块数下降，暗示I/O离散化——这往往是碎片加剧的信号
SYSAUX这类系统表空间的碎片要特别小心
像WRH$_ACTIVE_SESSION_HISTORY这种AWR历史表，在SYSAUX里常年增长，极易形成大而碎的段。它不会出现在FSFI计算里（因为是SYSTEM类表空间），但会真实挤占空间、拖慢快照生成。这时候必须查dba_segments按bytes排序，定位头部大对象，再结合MOS文档（如ID 387914.1）做分区清理，而不是盲目COALESCE。
