UNFORMATTED_BLOCKS 为0通常因未显式指定segment_type参数或类型不匹配；必须传入'segment_type => ''TABLE'''等明确值，且注意大小写、权限及统计信息完整性。
为什么 DBMS_SPACE.SPACE_USAGE 返回的 UNFORMATTED_BLOCKS 总是 0？
因为默认调用方式没指定 segment_type 或用了不匹配的段类型，oracle 只对 table 和 index 类型返回有效块级使用数据；如果传了 'table partition' 却查的是普通表，或者漏传 segment_type 参数（依赖默认值），结果就不可信。
- 必须显式传入
segment_type => 'TABLE'（或'INDEX'），不能依赖过程内部默认逻辑 - 对象名要区分大小写：如果表是双引号建的（如
"MyTable"），segment_owner和segment_name必须完全一致 - 执行用户需有
ANALYZE ANY或对象上的ANALYZE权限，否则部分字段返回空或 0 -
UNFORMATTED_BLOCKS为 0 不代表没空间浪费，可能是 HWM 下方有大量已删除但未回收的块，此时要看UNUSED_BLOCKS和FULLY_USED_BLOCKS的差值
DBMS_SPACE.SPACE_USAGE 和 DBMS_SPACE.UNUSED_SPACE 该选哪个？
看你要定位的问题：前者告诉你「HWM 下实际怎么用的」，后者只告诉你「HWM 上方还有多少空着」。想算真实水位线高度、评估收缩价值，必须用 SPACE_USAGE；只查还能插入多少行，UNUSED_SPACE 更快但信息太粗。
-
SPACE_USAGE需要扫描段头和位图块，耗时明显，大表建议在低峰期跑，且会触发一次逻辑读，可能影响 buffer cache -
UNUSED_SPACE不扫描数据块，只读段头，快但无法区分“已分配但未格式化”和“已格式化但为空”的块 - 两者都要求表已
ANALYZE或收集过统计信息，否则DBA_SEGMENTS.BLOCKS可能不准，导致计算偏差
怎么把 SPACE_USAGE 结果换算成真实水位线块数？
HWM 块数 ≈ TOTAL_BLOCKS − UNUSED_BLOCKS，但这个等式只在没有延迟块清除、无并行 DML 碎片时成立；更稳妥的做法是用 FULLY_USED_BLOCKS + FULLY_USED_BYTES / block_size 向上取整，再加 0.5 * PARTIALLY_USED_BLOCKS（估算半满块平均贡献）。
- 别直接信
TOTAL_BLOCKS：它来自DBA_SEGMENTS，可能滞后于实际分配（尤其开启 ASSM 自动段管理时） -
PARTIALLY_USED_BLOCKS数值波动大，一次查询可能比下一次少几十块——这是正常现象，因块状态在事务中动态变化 - 示例换算：
SELECT ROUND(fully_used_blocks + partially_used_blocks * 0.5) AS hwm_estimated_blocks FROM TABLE(DBMS_SPACE.SPACE_USAGE('SCOTT', 'EMP', 'TABLE'));
执行后发现 FULLY_USED_BLOCKS 比 NUM_ROWS / (BLOCKS / NUM_ROWS) 估算值小很多，正常吗？
非常正常。这个差异恰恰说明你表存在严重行迁移或链式行（CHAIN_CNT > 0），或者用了大字段（CLOB/VARCHAR2(32767)）导致单行跨多块。此时 FULLY_USED_BLOCKS 反映的是“有有效数据的块”，而你的估算假设每块塞满固定行数。
- 查
DBA_TAB_STATISTICS看AVG_ROW_LEN和CHAIN_CNT，若后者 > 0，优先处理行迁移（ALTER TABLE ... MOVE） - 用
ANALYZE TABLE ... LIST CHAINED ROWS定位具体哪些行链式存储，别只看平均值 - ASSM 表空间下，
PCTFREE设置过高也会压低FULLY_USED_BLOCKS，但不会让CHAIN_CNT上升
高水位线不是个静态数字，它是块状态、事务历史、存储参数三者动态博弈的结果；每次调用 DBMS_SPACE.SPACE_USAGE 得到的都是那个毫秒级快照，别拿两次结果直接相减算“释放了多少块”。
