drop tablespace ... including contents and datafiles 不保证物理文件删除，因需满足表空间非空、文件未被打开、非asm环境三条件，且物化视图日志等对象需手动清理，残留文件须检查句柄并停服务后删除。
不能靠一条命令就确保物理文件消失——DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES 成功返回，不代表 .dbf 文件真的从磁盘上删了。
为什么 INCLUDING CONTENTS AND DATAFILES 有时不删文件
这个语句的行为是：先删段对象、再从控制文件移除数据文件记录、最后尝试调用 OS 接口删除 .dbf。但实际能否删掉，取决于三个硬性条件：
- 表空间必须非空（否则
INCLUDING CONTENTS报错ORA-01911: contents keyword expected） - 所有数据文件不能被任何会话打开或读写（比如大查询正在扫该表空间的表，或归档进程正写入）
- 数据库不能使用 ASM —— 在 ASM 环境下，
AND DATAFILES完全无效，只删逻辑结构
Windows 上尤其常见：Oracle 进程独占打开文件，语句执行成功，但 .dbf 仍锁在磁盘上，需手动进目录删（且得确保 Oracle 服务账户有 NTFS 删除权限）。
删之前必须检查的阻塞点
即使语法正确、环境合规，以下对象也会让删除卡住或失败：
- 物化视图日志（
MATERIALIZED VIEW LOG）：属于独立段，INCLUDING CONTENTS不自动清理，得先DROP MATERIALIZED VIEW LOG ON t - 队列表（
QUEUE_TABLE）：需用DBMS_AQADM.DROP_QUEUE_TABLE显式删除 - Flashback Data Archive 关联的表：查
DBA_FLASHBACK_ARCHIVE_TABLES，先禁用归档再删 - 外键引用：其他表空间的表通过
FOREIGN KEY指向本表空间的主键表，不加CASCADE CONSTRAINTS会报ORA-02449
执行前跑一遍：SELECT owner, object_name, object_type FROM dba_objects WHERE tablespace_name = 'YOUR_TS' AND object_type IN ('MATERIALIZED VIEW LOG', 'QUEUE TABLE');
删完发现 .dbf 还在磁盘上怎么办
先确认控制文件是否已清理：SELECT file_name FROM dba_data_files WHERE tablespace_name = 'YOUR_TS_NAME'; 如果查不到，说明 Oracle 层已“失联”，但文件残留是 OS 层问题：
- Linux/Unix：检查文件句柄是否被占用 ——
lsof | grep your_ts_name，若有输出，说明进程还在 hold 文件，停库再删更安全 - Windows：直接进目录删，但务必先停止 OracleService
ORACLE_SID服务，避免权限冲突或句柄争用 - 别用
rm -f或资源管理器强制删正在被 Oracle 打开的文件，可能触发实例崩溃或数据字典不一致
真正容易被忽略的是：只要文件句柄没释放，哪怕删了，OS 层的空间就不会回收——df -h 或磁盘属性里看到的可用空间不会变。
