高频DELETE会形成表空间“空洞”，即逻辑空闲但物理未回收的数据块；表现为Buffer Gets异常高、Buffer Hit Ratio低于90%、latch: cache buffers chains等待飙升，且fill_ratio显著偏低。
高频 DELETE 为什么会让表空间“长空洞”
Oracle 的 DELETE 不真正释放数据块给操作系统，只标记为“可重用”。如果删除集中在某几张大表、且后续没有大量 INSERT 或 UPDATE 填充这些块，就会在段（segment）内部形成大量逻辑空闲但物理未回收的块——也就是“空洞”。AWR 本身不直接报告“空洞”，但它会暴露空洞引发的连锁症状：Buffer Gets 异常高、Physical Reads 比预期多、latch: cache buffers chains 等待飙升，甚至 db file sequential read 平均延迟突增。
- 空洞不会让表空间使用率下降，反而可能推高
SYSAUX或用户表空间中WRH$%分区表的体积（因统计信息采集更频繁、采样更细） - 真实业务中常见于日志类、流水类表按时间范围批量清理，但没配合
ALTER TABLE ... SHRINK SPACE或分区交换 - 注意区分：空洞 ≠ 高水位线（HWM）问题。HWM 是块地址上限，空洞是 HWM 下方的碎片化空白
从 AWR 报告里抓空洞的三个关键证据
别搜“空洞”这个词——AWR 没这个字段。要反向识别，盯紧这三处：
-
SQL ordered by Gets：找
DELETE语句的Buffer Gets per Exec。若单次执行 > 50000 且Rows Processed很小（比如删 10 行却读了 8 万块），说明在遍历大量空块 -
Instance Efficiency Percentages：看
Buffer Hit Ratio是否低于 90%，同时physical reads在 Load Profile 中占比异常升高——空洞导致 buffer cache 无法有效复用，反复物理读旧块 -
Top 5 Timed Events：若出现
latch: cache buffers chains且占比 > 10%，再叠加db file sequential readAv Rd(ms) > 25ms，基本可断定是热点空块争用（多个会话同时扫描同一片稀疏区域）
验证空洞存在：用 DBA_SEGMENTS + BLOCKS 算“填充率”
AWR 给的是宏观趋势，确认空洞得下钻到对象级。执行以下查询（替换 YOUR_SCHEMA 和 YOUR_TABLE）：
SELECT segment_name, blocks, num_rows, ROUND((num_rows * avg_row_len) / (blocks * 8192), 4) AS fill_ratio FROM dba_tables t JOIN dba_segments s ON t.owner = s.owner AND t.table_name = s.segment_name WHERE t.owner = 'YOUR_SCHEMA' AND t.table_name = 'YOUR_TABLE';
- 结果
fill_ratio - 若
num_rows为 0 但blocks很大，说明DELETE后没ANALYZE或DBMS_STATS更新统计信息，优化器仍按旧基数估算，加剧全表扫描 - 注意：该查询依赖统计信息准确性，生产环境建议先跑
EXEC DBMS_STATS.GATHER_TABLE_STATS('YOUR_SCHEMA','YOUR_TABLE')
高频 DELETE 场景下最易踩的三个坑
很多 DBA 一看到慢就加索引或调并行，反而掩盖了空洞本质：
- 盲目重建索引：空洞在表段，不在索引段。重建索引可能让
DELETE更慢（因为要维护新索引结构） - 用
TRUNCATE替代DELETE：虽清空快，但会锁整表、中断业务，且丢失事务一致性；高频场景应优先考虑分区自动滚动（INTERVAL分区 +DROP PARTITION） - 直接
SHRINK SPACE：需启用行移动（ENABLE ROW MOVEMENT），且会阻塞 DML；必须搭配ALTER TABLE ... SHRINK SPACE COMPACT先压缩再释放，避免长事务失败
空洞不是孤立现象，它和统计信息过期、执行计划劣化、latch 争用是咬合在一起的齿轮。AWR 报告里任何一处指标异常，都得拉出其他模块交叉印证——比如看到高 latch: cache buffers chains，必须立刻查对应 SQL 的执行计划是否用了全表扫描，再回溯这张表最近有没有大规模 DELETE 操作。漏掉任一环，优化就只是临时止血。
