TRUNCATE不缩小数据文件物理大小，仅重置HWM、释放segment空间；DBA_SEGMENTS显示释放但df-h无变化属正常，需DEALLOCATE UNUSED KEEP 0及依赖检查后才可RESIZE。
TRUNCATE 不会缩小数据文件（.dbf）的物理大小，它只重置高水位线（HWM）并释放 segment 内部空间，但操作系统层面的磁盘文件尺寸保持不变。
TRUNCATE 后 DBA_SEGMENTS 显示空间已释放，但 df -h 磁盘没变化
这是正常现象，不是操作失败。TRUNCATE 作用于逻辑段（segment），让 Oracle 认为那些块“可重用”，但不会把数据文件末尾的空闲空间还给操作系统。DBA_FREE_SPACE 里能看到 free space 上升，而 dba_data_files.bytes 仍维持原值。
- 检查是否真有可收缩空间：运行
SELECT file_name, bytes/1024/1024 curr_mb, (bytes - NVL((SELECT SUM(bytes) FROM dba_free_space WHERE file_id = d.file_id), 0))/1024/1024 used_mb FROM dba_data_files d WHERE tablespace_name = 'YOUR_TS'，确认curr_mb - used_mb > 100 - TRUNCATE 后若表含 LOB 字段，需额外检查
dba_lobs和dba_segments，LOB 段可能未被 DROP STORAGE 影响 - 如果表启用了
REUSE STORAGE（默认行为），则 MINEXTENTS 占用的空间也不会释放；加DROP STORAGE才能释放这部分
ALTER DATABASE DATAFILE RESIZE 总报 ORA-03297
报错说明文件末尾仍有已分配的 extent，哪怕表已被 TRUNCATE。Oracle 要求 RESIZE 的目标大小必须 ≤ 当前最后一个已分配 block 的位置，不能跨过“空洞”截断。
- 先执行
ALTER TABLE your_table DEALLOCATE UNUSED KEEP 0，强制把 HWM 下所有未用块标记为空闲（注意：需确保无活跃事务） - 再查
v$dbfile和dba_extents，确认该文件最高 extent 的block_id + blocks是否已回落到低位 - 仍失败？说明其他对象（如索引、IOT、LOB）还在占用高位 —— 需逐个检查
dba_extents中同 file_id 的最大block_id
TRUNCATE + DROP STORAGE 仍不生效的隐藏原因
常见于外键依赖、物化视图日志或 Flashback Data Archive 开启的场景。这些约束会让 Oracle 拒绝真正释放底层存储，表面成功但 segment 实际未收缩。
- 查依赖：
SELECT * FROM dba_constraints WHERE constraint_type IN ('R', 'U', 'P') AND r_constraint_name IN (SELECT constraint_name FROM dba_constraints WHERE table_name = 'YOUR_TABLE') - 有物化视图日志？运行
SELECT log_table FROM dba_mview_logs WHERE master = 'YOUR_TABLE'；存在则需加PRESERVE MATERIALIZED VIEW LOG或先清理 - 启用 Flashback Data Archive？
SELECT flashback_archive_name FROM dba_flashback_archive_tables WHERE table_name = 'YOUR_TABLE'—— 若返回结果，TRUNCATE 会被拒绝
真正释放磁盘空间的最后一环永远是 ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE NNNM，但它成败取决于前面是否清掉了高位 extent。别跳过 DEALLOCATE UNUSED KEEP 0 和依赖检查，这两步漏掉，RESIZE 必然失败。
