DROP TABLE仅释放段级空间，不缩小数据文件；需手动执行ALTER DATABASE DATAFILE ... RESIZE才能释放操作系统磁盘空间。
Oracle 删除大表后操作系统磁盘空间没变，不是删漏了，也不是权限问题，而是 DROP TABLE 只删段、不碰数据文件本身。
DROP TABLE 后 DBA_SEGMENTS 空间清零，但 .dbf 文件尺寸纹丝不动
执行 DROP TABLE big_table 后，DBA_SEGMENTS 中该表的记录消失，BYTES 归零，说明 Oracle 已释放段级空间——但这只是把块还给表空间（DBA_FREE_SPACE 增加），没通知操作系统回收物理文件。数据文件（如 /u01/oradata/ORCL/users01.dbf）的大小仍由文件系统决定，Oracle 不会自动 truncate() 或 unlink() 它。
- 现象：用
du -sh /u01/oradata/ORCL/users01.dbf查看，文件大小不变；df -h显示 OS 可用空间无增长 - 原因：Oracle 默认不启用自动收缩数据文件；文件头尾指针未移动，OS 无法感知“空洞”
- 例外：如果该表是表空间里唯一对象，且你用的是
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES，才可能触发 OS 层删除（依赖 Oracle 版本和 OS 权限）
真正释放 OS 磁盘空间必须手动 RESIZE 数据文件
SHRINK SPACE 对已删的表无效——它只作用于现存表段；要让 .dbf 缩小，得直接操作数据文件本身：
- 先确认目标文件是否可安全缩小：
SELECT file_id, bytes/1024/1024 AS mb, autoextensible FROM dba_data_files WHERE file_name = '/u01/oradata/ORCL/users01.dbf' - 查实际高水位位置：
SELECT MAX(block_id + blocks - 1) * 8192 AS high_water_bytes FROM dba_extents WHERE file_id = &file_id（结果即为可缩到的最小字节数） - 执行收缩：
ALTER DATABASE DATAFILE '/u01/oradata/ORCL/users01.dbf' RESIZE 500M（值必须 ≥ 上一步查出的high_water_bytes） - 若报
ORA-03297，说明文件末尾仍有 Extent 分配，需先MOVE表或用DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_FREELISTS整理
容易被忽略的关键点：文件组归属与 AUTOEXTEND 设置
很多 DBA 在 RESIZE 失败后反复试错，却忘了检查两个硬性前提：
- 目标数据文件是否属于
SMALLFILE表空间？BIGFILE表空间只允许一个文件，RESIZE是唯一收缩手段，但不能DROP单个文件 -
AUTOEXTEND ON的文件即使当前未用满，RESIZE也不能低于MINEXTENTS × INITIAL计算出的理论下限，否则报错 - RAC 环境下，
RESIZE必须在所有实例都处于 MOUNT 状态时执行，否则仅影响当前实例缓存，OS 层不生效
最常卡住的地方，其实是误以为 “删完表就等于删完文件”。Oracle 的空间管理是分层的：段 → 区 → 块 → 文件 → OS。越往底层走，越需要显式干预，DROP TABLE 只管第一层。
