必须先断开所有会话再加 cascade 删除用户，否则报 ORA-01940；需用大写用户名查询 v$session，杀 ACTIVE 和 INACTIVE（last_call_et>0）会话，kill 后等待 5–10 秒或使用 immediate 参数，锁账户后再删更稳妥。
不能直接删，必须先断开所有会话，再加 cascade 删除；否则必报 ora-01940: cannot drop a user that is currently connected。
查不到活跃会话，但还是删不掉用户？
常见于应用持续重连、连接池未释放或会话状态为 INACTIVE 但尚未真正断开。仅靠 select * from v$session where username = 'XXX' 可能漏掉后台连接（比如 JDBC 连接池的保活心跳）。
- 务必用大写用户名查询：
where username = 'MYUSER'（Oracle 默认转大写） - 检查
status字段：除了ACTIVE，INACTIVE且last_call_et > 0的会话也得杀 - 补充查监听进程：
select program, machine, osuser from v$session where username = 'MYUSER'，确认是否来自应用服务器而非 DBA 误连
alter system kill session 后仍报 ORA-01940？
杀完会话不等于连接立刻消失——Oracle 需要时间清理 PGA、释放锁、回滚事务。如果立刻执行 drop user，可能因残留会话元数据失败。
- 执行
kill session后，等 5–10 秒再查v$session，确认结果为空 - 若仍有残留，加
immediate参数强制终止：alter system kill session 'sid,serial#' immediate - 极端情况（如会话卡在回滚），可查
v$transaction确认是否真在事务中；若无，基本是连接池缓存导致的“假连接”
不想停应用，又想安全删用户？
核心思路是“阻断新连接 + 清空现存会话”，比硬杀更稳妥。适用于测试/开发环境微服务无法统一停机的场景。
- 先锁账户：
alter user MYUSER account lock，阻止后续登录 - 再批量杀当前会话（含
INACTIVE）：select 'alter system kill session '''||sid||','||serial#||''' immediate;' from v$session where username = 'MYUSER' - 确认无残留后执行：
drop user MYUSER cascade - 注意：新建同名用户时，密码别立刻设回原值，否则连接池会瞬间重连写入，可能破坏导入中的数据一致性
最容易被忽略的是锁用户后没等连接池超时就删——有些 Java 应用连接池默认重试间隔 30 秒，此时会话虽被 kill，但应用仍在疯狂重连，导致 v$session 反复出现新记录。实际操作中，建议锁用户后观察 2 分钟再删。
