查高水位线必须先收集统计信息,因user_tables.blocks反映的是曾使用过的块数(即hwm位置),若未分析表则该值不准;需执行dbms_stats.gather_table_stats或analyze table;再结合blocks、empty_blocks及dbms_rowid计算真实占用块数来评估碎片。

查高水位线必须先收集统计信息
直接查 USER_TABLES.BLOCKS 是不准的,因为 BLOCKS 字段反映的是“曾经使用过的数据块数”,即高水位线(HWM)位置,但它依赖统计信息是否最新。没分析过表,BLOCKS 可能是旧值甚至为 0。
必须先执行统计信息收集:
-
ANALYZE TABLE table_name COMPUTE STATISTICS(旧方式,仍可用) - 更推荐:
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'TABLE_NAME')
注意:GATHER_TABLE_STATS 默认不收集列直方图,如需更精细评估碎片,可加 method_opt => 'FOR ALL COLUMNS SIZE AUTO'。
用 USER_TABLES 查 BLOCKS 和 EMPTY_BLOCKS
USER_TABLES 视图里两个关键字段就是判断 HWM 的核心依据:
-
BLOCKS:高水位线以下已格式化、至少曾被使用过的数据块数 → 即 HWM 位置 -
EMPTY_BLOCKS:分配给该段、但在 HWM 之上的空闲块数 → 这些块从未写入过数据
典型查询:
SELECT table_name, num_rows, blocks, empty_blocks, last_analyzed FROM user_tables WHERE table_name = 'YOUR_TABLE';
如果 BLOCKS 很大但 NUM_ROWS 很小,且 EMPTY_BLOCKS 接近 0,说明 HWM 下有大量已格式化但当前为空的块(即“内部碎片”),这是 delete 后未 shrink 的典型表现。
验证实际数据占用块数(绕过 HWM 陷阱)
BLOCKS 是 HWM 值,不代表当前真实数据占多少块。要算“真·活跃块数”,得按行实际分布来统计:
- 用
DBMS_ROWID提取每行所在数据块号 + 文件号去重计数:
SELECT COUNT(DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) || '-' ||
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID)) AS used_blocks
FROM your_table;
这个结果才是当前数据真正散落在多少个物理块上。如果它远小于 BLOCKS(比如 42 vs 716119),就确认存在严重 HWM 偏高问题。
注意:该查询在大表上可能较慢,建议在业务低峰或加 WHERE ROWNUM 抽样估算。
区分段级总空间和 HWM 级别空间
很多人混淆 DBA_SEGMENTS.BYTES 和 USER_TABLES.BLOCKS:
-
DBA_SEGMENTS.BYTES是分配给该段的**全部空间**(含 HWM 上下所有已分配区) -
USER_TABLES.BLOCKS是 HWM 位置,只含 HWM **以下**的块(已格式化块)
所以会出现:一个空表 DBA_SEGMENTS.BYTES 是 65536(即 8 块 × 8K),但 USER_TABLES.BLOCKS 是 8 —— 因为初始区已格式化,HWM 就在第 8 块之后。
真正要定位“浪费在哪”,得比对三者:DBA_SEGMENTS.BYTES(总分配)、USER_TABLES.BLOCKS × 8192(HWM 下空间)、used_blocks × 8192(真实占用)。差值越大,越值得 shrink。
EMPTY_BLOCKS > 0,也不能说明 HWM 可被自动下移 —— Oracle 永远不会自己回收 HWM 下的空块,除非你显式执行 SHRINK SPACE 或 MOVE。











