DROP TABLESPACE 不加 INCLUDING CONTENTS AND DATAFILES 仅删除数据字典记录，物理文件仍存在，磁盘空间不释放；必须显式指定该子句并确保无依赖、无活跃会话、非系统表空间等前提，且删后需检查 lsof 确认文件句柄已释放。
直接执行 DROP TABLESPACE 不删物理文件，磁盘空间不会释放——必须显式加 INCLUDING CONTENTS AND DATAFILES 才能真正清理干净。
为什么 DROP TABLESPACE tablespace_name 后磁盘空间没变？
Oracle 默认只删逻辑结构：DROP TABLESPACE 仅移除数据字典记录，DBA_DATA_FILES 里还能查到原路径，.dbf 文件仍躺在磁盘上。这不是 bug，是设计行为：不带 INCLUDING CONTENTS 就等同于“只删空壳”。常见错误是误以为表空间“空了”就能直接删，结果语句报 ORA-01549 或删完空间照占。
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 的硬性前提
这条命令看似一键清空，但跳过检查大概率失败或残留对象：
- 确认不是系统表空间：
SELECT * FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS'，排除SYSTEM、SYSAUX、UNDOTBS1、TEMP等不可删项 - 检查是否为用户默认表空间：
SELECT username, default_tablespace FROM dba_users WHERE default_tablespace = 'YOUR_TS'，若有，先执行ALTER USER xxx DEFAULT TABLESPACE users - 确认无活跃会话占用：
SELECT sid, serial#, username FROM v$session WHERE username IN (SELECT username FROM dba_users WHERE default_tablespace = 'YOUR_TS')，有则用ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE - 检查是否有 Flashback Data Archive 或 GoldenGate 依赖：
SELECT * FROM dba_flashback_archive_tables WHERE tablespace_name = 'YOUR_TS'
删完后 df -h 还看不到空间回收？
这是 Oracle 19c 在 Linux/Unix 上的典型现象：执行 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 后，Oracle 调用 unlink() 删除文件，但若 DBWn、CKPT 等后台进程仍持有该文件句柄，内核不会真正释放磁盘块。
验证方式：lsof | grep 'deleted'，看到类似 /u01/oradata/ORCL/ts_historical01.dbf (deleted) 就是它。
两种处理方式：
- 轻量级：找出 PID（如
lsof | grep 'ts_historical.*deleted' | awk '{print $2}'），执行kill -9 <pid>，等 10–30 秒再df -h - 彻底但停机：执行
SHUTDOWN IMMEDIATE+STARTUP，强制关闭所有句柄
配套清理不能漏：用户和残留权限
表空间删了，但用户还在，下次建同名用户可能默认分到已删表空间，引发奇怪错误（如 ORA-01950: no privileges on tablespace）。
务必顺手执行：
-
DROP USER your_user CASCADE——CASCADE是关键，否则残留同义词、角色权限会导致后续重建失败 - 检查
SELECT file_name FROM dba_data_files WHERE tablespace_name = 'YOUR_TS'应返回空集 - 操作系统层面确认
.dbf文件确实消失，而非仅标记为(deleted)
最易被忽略的点：删完不查 lsof，就以为空间已释放；或者忘了切走默认表空间，导致新用户建表直接报错。这些都不是语法问题，而是环境状态没对齐。
