truncate partition 默认不释放物理空间，仅重置hwm；必须显式加 drop storage 才可能回收extents，且受段结构限制；还需配合 update global indexes 避免索引失效。
分区表 TRUNCATE PARTITION 为什么空间没变
执行 ALTER TABLE t TRUNCATE PARTITION p1 后，DBA_SEGMENTS.BYTES 或 DBA_EXTENTS.COUNT 没变化——这不是延迟刷新，而是默认行为只重置该分区的高水位线（HWM），不主动归还 extents。Oracle 把这部分空间标记为“可重用”，但不会立刻从 segment 中剥离并交还给表空间。
- 默认等价于
TRUNCATE PARTITION p1 DROP STORAGE，但是否真释放，取决于该分区当前分配的 extents 是否连续、是否位于 HWM 下方空闲区之间 - 若该分区曾经历大量 INSERT/DELETE 导致碎片化，
DROP STORAGE可能只收缩到第一个可用 extent，而非彻底清空 - 如果表使用
REUSE STORAGE（比如之前被TRUNCATE ... REUSE STORAGE过），则本次TRUNCATE PARTITION也不会释放任何空间
必须加 DROP STORAGE 才可能释放物理段空间
DROP STORAGE 是显式触发空间回收的关键子句，但它不是万能开关：它只对当前分区生效，且仅在满足底层段结构条件时才真正削减 extents 数量。
- 正确写法：
ALTER TABLE t TRUNCATE PARTITION p1 DROP STORAGE - 错误写法：
ALTER TABLE t TRUNCATE PARTITION p1（无子句，默认虽等价但受 ASSM 和 extent 分布限制） - 注意：不能写成
DROP (STORAGE)或REUSE STORAGE—— 后者会完全禁用释放，前者语法非法 - 执行后立即查
SELECT COUNT(*) FROM DBA_EXTENTS WHERE SEGMENT_NAME = 't' AND PARTITION_NAME = 'p1'，若返回 0 或接近MINEXTENTS值（如 1），说明释放成功
全局索引失效是常见连带故障
分区级 TRUNCATE 不维护全局索引，执行后对应全局索引状态会变成 UNUSABLE，导致后续查询走全表扫描或报 ORA-01502。
- 修复方式只有两种：
ALTER INDEX idx REBUILD（锁表、耗时），或提前加UPDATE GLOBAL INDEXES - 推荐做法：
ALTER TABLE t TRUNCATE PARTITION p1 DROP STORAGE UPDATE GLOBAL INDEXES - 注意：
UPDATE GLOBAL INDEXES不等于重建索引，它只是同步更新索引条目指向，索引段本身的空间不会缩小；若索引已严重膨胀，仍需单独REBUILD - 本地索引不受影响，但实践中发现部分版本（如 19c）在高并发插入时仍有性能抖动，建议对刚截断的分区所涉本地索引也执行
ALTER INDEX idx REBUILD PARTITION p1
真正释放不了？那就绕过 TRUNCATE 走物理重组
当 TRUNCATE PARTITION ... DROP STORAGE 仍无法降低 DBA_SEGMENTS.BYTES，说明该分区的 extents 已“钉死”在段结构里，必须打破逻辑段边界。
- 方案一（在线、低风险）：
ALTER TABLE t MODIFY PARTITION p1 SHRINK SPACE，前提是已执行ENABLE ROW MOVEMENT，且无函数索引等阻碍项 - 方案二（彻底、停机）：
ALTER TABLE t EXCHANGE PARTITION p1 WITH TABLE t_staging+DROP TABLE t_staging，再重建分区（适合配合归档流程） - 方案三（大表首选）：用
expdp导出该分区数据 →DROP PARTITION p1→impdp重新导入，能清理元数据和 extent 碎片，但需额外存储空间 - 关键提醒：所有这些操作都不会缩小数据文件（
.dbf）物理大小，要缩文件得单独ALTER DATABASE DATAFILE ... RESIZE，且只能缩到 HWM 以下空闲区上限
DROP STORAGE，DBA_EXTENTS 还是一堆记录”——这往往是因为分区刚被大量 DELETE 过，extent 链表未整理，DROP STORAGE 找不到连续可回收区间。这时候别硬等，直接上 SHRINK 或换分区交换更省事。
