不能跳过检查直接执行 drop tablespace，否则易残留数据文件、触发 ora-01119/ora-02429 错误，磁盘不释放且重名重建失败；必须验证默认/临时表空间引用、活动临时段、lob/索引分离存储，并区分 omf 与非 omf 环境下 including contents and datafiles 的实际效果，手动确认并清理物理文件。
直接说结论：不能跳过检查就执行 DROP TABLESPACE，否则大概率残留数据文件、触发 ORA-01119 或 ORA-02429 错误，磁盘空间不释放，下次建同名表空间直接失败。
确认表空间是否真的“可删”
很多人以为查不到对象就等于安全，其实不然。表空间可能被其他用户设为默认表空间、或有临时段/回滚段残留、甚至存在跨表空间依赖（比如主键索引在别的表空间）。必须逐项验证：
- 查是否有用户以该表空间为
default_tablespace或temporary_tablespace：SELECT username, default_tablespace, temporary_tablespace FROM dba_users WHERE default_tablespace = 'YOUR_TS' OR temporary_tablespace = 'YOUR_TS'; - 查是否还有活动会话正在用这个表空间的临时段：
SELECT s.sid, s.username, u.tablespace FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr AND u.tablespace = 'YOUR_TS'; - 查是否存在 LOB 段或索引分离存储：
SELECT owner, table_name, column_name, tablespace_name FROM dba_lobs WHERE tablespace_name = 'YOUR_TS';和SELECT owner, index_name, tablespace_name FROM dba_indexes WHERE tablespace_name = 'YOUR_TS';
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 的真实行为
这是 Oracle 12c+ 推荐的一体化删除方式，但它不是“万能保险”。关键点在于：
-
INCLUDING CONTENTS AND DATAFILES会调用 Oracle 内部机制尝试同步删除操作系统级文件——但仅当数据库使用 OMF（Oracle Managed Files）时才真正生效；非 OMF 环境下，它仍可能只删元数据，留下孤儿文件。 - 它隐式要求所有对象处于“可清理状态”：不能有跨表空间约束、不能有未提交事务、不能有正在使用的临时段。一旦不满足，语句直接报错（如
ORA-02429），不会半途而废。 - 它不处理
TEMPFILE：如果表空间含临时文件（CREATE TEMPORARY TABLESPACE创建的），必须单独执行DROP TEMPFILE 'xxx.dbf'，否则文件残留。
手动清理残留数据文件的必要步骤
无论你用了 INCLUDING CONTENTS AND DATAFILES 还是只用了 INCLUDING CONTENTS，都必须验证并清理物理文件：
- 先查路径：
SELECT file_name FROM dba_data_files WHERE tablespace_name = 'YOUR_TS'; - 登录数据库服务器，确认这些文件是否还存在：
ls -l /path/to/users01.dbf（Linux）或dir C:\oradata\...\users01.dbf（Windows） - 若存在且确认无误，再执行系统级删除：
rm /u01/oradata/orcl/your_ts01.dbf（Linux）或del C:\oradata\orcl\your_ts01.dbf（Windows） - 特别注意：不要用
rm -rf批量删整个目录，容易误伤其他表空间文件
为什么加了 CASCADE CONSTRAINTS 还报错？
CASCADE CONSTRAINTS 对 DROP TABLESPACE 是无效语法——Oracle 会直接报 ORA-02429 或 PLS-00103。这个子句只在 DROP TABLE 中合法。表空间级的约束清理靠的是对象本身的可删除性，而不是这个开关。
真正要解决约束报错，得提前处理依赖：把引用本表空间表的外键所对应的索引、主键、唯一约束，全部迁移到目标表空间内（用 ALTER INDEX ... REBUILD TABLESPACE xxx），或者先删掉依赖方的对象。这不是一步 SQL 能绕过的逻辑闭环。
最易被忽略的点：临时文件没删、LOB 分离存储没查、OMF 环境误判、以及删完没登系统确认文件是否真没了——这四点加起来，占了生产环境表空间“删而未净”的 90% 以上原因。
