oracle表空间碎片本质是空闲区分散不连续，真正反映碎片程度的是空闲区能否被有效利用；需通过dba_free_space分析空闲区分布，并用dbms_space.space_usage评估段级逻辑碎片。
查 DBA_FREE_SPACE 中空闲区分布，不是看总量而是看离散度
直接 SELECT SUM(bytes) 得到的是“空闲总空间”，完全不能反映碎片化程度。真正影响分配能力的是空闲区（extent）是否细碎、不连续。关键指标是：MIN(bytes) 是否极小（KB级）、COUNT(*) 是否远大于 SUM(bytes)/AVG(bytes) 的理论值。
执行这个查询能一眼看出问题：
SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024, 2) AS "FREE_MB", COUNT(*) AS "FREE_EXTENTS", ROUND(MIN(bytes)/1024/1024, 3) 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;
-
MIN_MB≤ 0.001（即 1 KB）且FREE_EXTENTS> 500 → 物理碎片严重，大对象可能无法分配 -
MAX_MB≥ 500 且FREE_EXTENTS同时很高 → 空闲区两极分化，说明有长期未回收的大块 + 新增的小块 - 字典管理表空间（
extent_management = 'DICTIONARY'）才适用此分析；ASSM 表空间的dba_free_space是逻辑视图，不能代表物理碎片
用 DBMS_SPACE.SPACE_USAGE 查单个段的真实块级填充率
表空间级碎片是宏观问题，但性能瓶颈常来自具体表或索引段。DBMS_SPACE.SPACE_USAGE 返回 fs1–fs4（空闲率 0–25%、25–50%、50–75%、75–100%）和 full_blocks，比 num_rows × avg_row_len 估算准得多。
必须满足：表在 ASSM 表空间中、不含 BASICFILE LOB、调用者有 EXECUTE 权限 on DBMS_SPACE。
典型调用（以表 EMPLOYEES 为例）：
DECLARE
l_unformatted_blocks NUMBER;
l_fs1_blocks NUMBER; l_fs2_blocks NUMBER;
l_fs3_blocks NUMBER; l_fs4_blocks NUMBER;
l_full_blocks NUMBER;
BEGIN
DBMS_SPACE.SPACE_USAGE(
segment_owner => 'HR',
segment_name => 'EMPLOYEES',
segment_type => 'TABLE',
unformatted_blocks => l_unformatted_blocks,
fs1_blocks => l_fs1_blocks,
fs2_blocks => l_fs2_blocks,
fs3_blocks => l_fs3_blocks,
fs4_blocks => l_fs4_blocks,
full_blocks => l_full_blocks
);
DBMS_OUTPUT.PUT_LINE('Full: ' || l_full_blocks);
DBMS_OUTPUT.PUT_LINE('FS1 (0-25%): ' || l_fs1_blocks);
DBMS_OUTPUT.PUT_LINE('FS2 (25-50%): ' || l_fs2_blocks);
END;
- 若
fs1_blocks + fs2_blocks远高于full_blocks→ 大量低填充率块，是典型的 delete 后未 shrink 导致的逻辑碎片 - 结果中
unformatted_blocks非零，说明 HWM 以上还有未格式化的空间，但该空间不可用于 INSERT（除非 shrink） - 注意：该过程不返回字节量，只返回块数；需结合
dba_tablespaces.block_size换算
别误把高水位线（HWM）当碎片，它只是“已用”与“未用”的分界
HWM 本身不是碎片，它是段中最后一个被使用过的数据块位置。HWM 以下有大量空块（empty_blocks），或者 usage_rate 低于 0.3，才是表级碎片信号。
判断前务必先更新统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'TABLE_NAME');
再查：
SELECT table_name, blocks * 8 / 1024 AS "HWM_MB", (num_rows * avg_row_len) / 1024 / 1024 AS "USED_MB", ROUND((num_rows * avg_row_len) / (blocks * 8192), 3) AS "USAGE_RATE" FROM user_tables WHERE table_name = 'YOUR_TABLE';
-
USAGE_RATEALTER TABLE ... SHRINK SPACE），但需启用行移动 -
empty_blocks> 0 且blocks明显偏大 → HWM 未回落，delete 操作未释放空间 - 不要对含 LONG 或未启用
ROW MOVEMENT的表直接 shrink，会报ORA-10636
ASSM 表空间下，dba_free_space 的碎片值基本没意义
自动段空间管理（ASSM）用位图跟踪空闲空间，dba_free_space 里的每条记录只是位图中一个“空闲区间”的逻辑映射，不是真实物理空闲 extent。所以即使看到几百个 FREE_EXTENTS，也不代表磁盘上真有几百个分散的物理块。
ASSM 下真正要盯的是：
- 段级：用
DBMS_SPACE.SPACE_USAGE看fs1～fs4分布 - 表空间级：关注
dba_data_files.bytes - (SELECT SUM(bytes) FROM dba_segments WHERE tablespace_name = ...)的差值是否异常大（说明 HWM 上方积压了大量未格式化空间） - 扩展失败：出现
ORA-01653（无法扩展表）或ORA-01631（无法扩展索引），往往不是缺空间，而是 ASSM 位图里找不到足够大的连续位图单元 —— 这才是 ASSM 下的“碎片”本质
