Oracle 11g+中DROP TABLE后表空间未减小，是因为默认启用回收站机制，执行的是软删除：表被重命名为BIN$xxx格式并移入user_recyclebin，段仍占用原数据文件空间；需执行PURGE操作（如PURGE RECYCLEBIN）才能真正释放段空间，但不会自动缩小数据文件。
Oracle 11g+ 默认启用回收站，DROP TABLE 是软删除
执行 DROP TABLE test 后表空间没变小，不是数据库卡顿或延迟，而是 Oracle 把表重命名成 BIN$xxx 格式、移入回收站（user_recyclebin），段（segment）仍占用原数据文件空间。你查 dba_segments 看不到 TEST，但查 user_recyclebin 能看到它和占用的 space 值——这正是“虚高”的来源。
- 确认是否在回收站：运行
SELECT original_name, object_name, space*8/1024 AS mb FROM user_recyclebin WHERE original_name = 'TEST'; - 回收站里的对象可被
FLASHBACK TABLE test TO BEFORE DROP;恢复，这是设计目的，不是 bug - DBA 可查全库回收站：
SELECT * FROM dba_recyclebin;（需权限）
PURGE 才真正释放段空间，但不等于文件收缩
PURGE 操作会从数据文件中物理删除 segment，但仅影响段级空间管理，不改变数据文件（.dbf）物理大小。常见误操作是 purge 后立刻查 dba_free_space 总和，发现没变化——其实空间已标记为“空闲”，只是未合并或未被操作系统感知。
- 清空当前用户回收站：
PURGE RECYCLEBIN; - 只清某张表：
PURGE TABLE test; - 跳过回收站直接删：
DROP TABLE test PURGE;（推荐用于确定不再恢复的场景） - 即使 purge 完成，
dba_free_space的空闲块可能分散，尤其在 ASSM 表空间中；若后续建表报ORA-01653，才说明真缺空间
TRUNCATE 或 DELETE 后空间也不释放？那是 HWM 和段管理机制
很多人混淆了 DROP、TRUNCATE、DELETE 的空间行为。TRUNCATE 默认等价于 TRUNCATE TABLE ... DROP STORAGE，但它只重置高水位线（HWM），不强制归还 extents；DELETE 更彻底——它连 HWM 都不动，只标记行删除。三者都不会让 .dbf 文件缩小。
-
DELETE：数据块保留在 HWM 下，dba_segments.bytes完全不变 -
TRUNCATE：HWM 归零，但已分配的 extents 可能仍被保留（尤其大表刚膨胀过） - 想真正回落磁盘占用：得走
ALTER TABLE ... SHRINK SPACE（需先ENABLE ROW MOVEMENT）或重建表（MOVE+REBUILD INDEX） - 最后一步常被跳过：
ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE 10240M;—— 必须确认末尾有连续空闲空间才安全执行
别只盯 dba_free_space，看后续 DML 是否失败才是硬指标
监控空间是否真正可用，不能依赖 dba_free_space 的汇总值或图形化工具显示的“使用率”。Oracle 的空间分配是 lazy 的：空闲 extent 可能碎片化、跨区、或受位图块状态限制。更可靠的判断方式是观察业务行为。
- 执行
CREATE TABLE t AS SELECT * FROM dual;或插入少量数据，看是否报ORA-01653（无法扩展表）或ORA-01658（无法创建初始 extent） -
dba_segments.bytes长期虚高是常态，尤其在频繁增删的 OLTP 表上 - ASSM 表空间中，
coalesce对本地管理无效；字典管理表空间才支持ALTER TABLESPACE ... COALESCE - 真正释放磁盘空间的闭环是：PURGE / SHRINK → 确认
dba_free_space出现大块连续空闲 →RESIZE DATAFILE
实际操作中，最易被忽略的是最后一环：以为 purge 或 shrink 完就万事大吉，结果磁盘空间一直没回来——因为没人去 resize 数据文件。
