必须先杀会话再删用户，否则drop user cascade报ora-01940；杀会话需查v$session、用immediate强制终止，删用户后还需手动清理表空间文件、残留对象及归档/rman备份。
先杀会话，再删用户，否则 DROP USER CASCADE 会报 ORA-01940
Oracle 不允许删除当前有活跃连接的用户，DROP USER ... CASCADE 直接执行会立刻失败，报错 ORA-01940: cannot drop a user that is currently connected。这不是权限问题，是数据库强制保护机制。
必须先查、再杀、最后删：
- 用
SELECT sid, serial#, status FROM v$session WHERE username = 'YOUR_USER'找出所有会话 - 对每个
status = 'ACTIVE'的会话，优先用ALTER SYSTEM KILL SESSION 'sid,serial#' POST_TRANSACTION等事务自然结束；若等不及，再改用IMMEDIATE - 杀完后，再执行
DROP USER YOUR_USER CASCADE
注意：POST_TRANSACTION 不会中断正在写的事务，但 IMMEDIATE 可能导致事务回滚——如果应用没做异常处理，可能丢数据。
删完用户后，表空间和数据文件还在磁盘上
DROP USER ... CASCADE 只清理数据字典（DBA_OBJECTS、DBA_SEGMENTS 等），完全不碰物理文件。如果你给用户分配了独立表空间（比如 USER_DATA_01），那些 .dbf 文件会原封不动留在磁盘里，长期积累就是“看不见的磁盘爆满”。
确认是否要删文件，分三步走：
- 查用户默认/临时表空间：
SELECT default_tablespace, temporary_tablespace FROM dba_users WHERE username = 'YOUR_USER' - 查这些表空间挂载的数据文件：
SELECT file_name, bytes/1024/1024 AS mb FROM dba_data_files WHERE tablespace_name IN (...) - 确认该表空间是否真被独占：
SELECT DISTINCT owner FROM dba_segments WHERE tablespace_name = 'YOUR_TBS'—— 如果只返回你刚删的用户名（或空），才安全删表空间
删表空间命令必须带两个关键词：DROP TABLESPACE YOUR_TBS INCLUDING CONTENTS AND DATAFILES。漏掉 AND DATAFILES，文件还在。
删表空间前，务必检查残留对象和未授权同义词
即使用户已删，DBA_OBJECTS 里也可能残留东西：物化视图日志、队列表（DBA_QUEUE_TABLES）、甚至其他用户建的同义词（DBA_SYNONYMS）指向已删用户的对象。这些会让 DROP TABLESPACE 报 ORA-01549 或 ORA-00942。
必须手动扫一遍：
- 查残留对象：
SELECT owner, object_type, object_name FROM dba_objects WHERE owner = 'YOUR_USER'—— 结果为空才过关 - 查残留队列：
SELECT queue_table FROM dba_queue_tables WHERE owner = 'YOUR_USER' - 查跨用户同义词：
SELECT owner, synonym_name FROM dba_synonyms WHERE table_owner = 'YOUR_USER'
这些对象不会自动级联删除，得一个个手动 DROP 或 REVOKE 掉引用权限。
归档日志和 RMAN 备份里还存着已删用户的数据
用户删了，但归档日志（ARCHIVELOG）和 RMAN 备份里仍保留其数据块镜像。如果之后做不完全恢复（RECOVER DATABASE UNTIL TIME ...），那个用户可能又“复活”了。
真正彻底，得清理备份链：
- 删归档：
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'（按需调整时间） - 删 RMAN 备份：
DELETE OBSOLETE或DELETE BACKUP COMPLETED BEFORE 'SYSDATE-30' - 确认清理效果：
LIST EXPIRED BACKUP+CROSSCHECK BACKUP
这一步最容易被跳过——毕竟不影响当前库运行，但会埋下恢复时“数据意外重现”的坑。
