执行 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 前必须确保表空间脱机、无活动依赖、回收站清空、无用户默认绑定及跨表空间外键引用，且需加 CASCADE CONSTRAINTS；INCLUDING DATAFILES 不保证物理文件被删除，OS 层句柄未释放时需手动清理。
执行 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 前必须确认表空间已脱机且无活动依赖
直接对脱机表空间运行 DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 仍会失败——Oracle 不检查物理状态，而检查数据字典一致性。即使表空间是 OFFLINE，只要它包含被其他用户默认引用的段、外键约束、物化视图日志或未清空的回收站对象，语句就会中断。常见报错包括 ORA-02449（外键引用）、ORA-01911（漏写 INCLUDING CONTENTS）、ORA-01546（含活动回滚段）。务必先用以下语句交叉验证：
-
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS';—— 确认状态不是READ ONLY或ONLINE -
SELECT owner, object_name, object_type FROM dba_objects WHERE tablespace_name = 'YOUR_TS';—— 必须返回空集 -
SELECT original_name FROM dba_recyclebin WHERE ts_name = 'YOUR_TS';—— 若有结果，先执行PURGE TABLESPACE YOUR_TS; -
SELECT username FROM dba_users WHERE default_tablespace = 'YOUR_TS' OR temporary_tablespace = 'YOUR_TS';—— 若有用户绑定，需先ALTER USER ... DEFAULT TABLESPACE ...
ALTER TABLESPACE ... OFFLINE 后不能直接删数据文件，必须删整个表空间
有人误以为“表空间已脱机，就可以逐个删里面的数据文件”，这是危险误区。Oracle 11g 中，ALTER TABLESPACE ... DROP DATAFILE 要求该数据文件为空、在线、且非首个文件；而脱机状态下，该命令直接报 ORA-03264（本地管理表空间不支持脱机数据文件删除）。更关键的是：脱机仅改变访问状态，不释放段占用，也不清空 extent 分配。所以试图用 ALTER TABLESPACE ts_name DROP DATAFILE 'xxx.dbf' 处理脱机表空间，99% 会失败。唯一可靠路径是整表空间级清理。
加 CASCADE CONSTRAINTS 不是可选项，而是外键存在时的强制前提
如果其他表空间中的表通过外键指向本表空间的主键表（哪怕该主键表本身已 DROP），Oracle 仍会在元数据中保留约束引用。此时不加 CASCADE CONSTRAINTS，DROP TABLESPACE 必报 ORA-02449。注意：CASCADE CONSTRAINTS 只删除约束定义，不影响外键所在表的数据或结构，也不会触发级联删除行。但必须明确：它只解决约束元数据阻塞，不解决数据残留问题。执行前建议快速扫一遍：
SELECT owner, constraint_name, constraint_type, r_owner, r_constraint_name FROM dba_constraints WHERE r_constraint_name IN (SELECT constraint_name FROM dba_constraints WHERE constraint_type IN ('P','U') AND owner IN (SELECT owner FROM dba_segments WHERE tablespace_name = 'YOUR_TS'));- 若结果非空，说明存在跨表空间外键依赖，
CASCADE CONSTRAINTS必须加上
物理文件残留不是语句失败，而是 OS 层 unlink 失败
INCLUDING DATAFILES 成功返回，并不代表磁盘上 .dbf 文件已被删除。在 Windows 上，Oracle 进程可能仍独占打开该文件；在 Linux 上，若有备份进程、rsync 或监控工具持有文件句柄（lsof | grep your_ts.dbf 可查），unlink() 调用就会静默失败。此时 dba_data_files 查不到记录，但文件仍在磁盘上，且占用空间不释放。最稳妥的做法是：
- 确认数据库已关闭（
SHUTDOWN IMMEDIATE） - 手动进入文件所在目录，用操作系统命令删除（Windows 用
del /f，Linux 用rm -f） - 切勿在数据库运行时强行 kill 进程去释放句柄——可能损坏控制文件
真正容易被忽略的是：只要文件句柄没关闭，即便 Oracle 认为“已删”，OS 就不会回收磁盘空间。这点在容器或 NFS 挂载环境下尤为明显。
