ORA-01940错误需先终止用户所有活跃会话再删除：查v$session定位连接，用alter system kill session 'sid,serial#'终止，确认会话状态为KILLED或消失后，执行drop user username cascade。
ora-01940 报错时不能直接 drop user，必须先终止该用户所有活跃会话。
查用户当前连接：用 v$session 定位活跃会话
Oracle 不允许删除有活动连接的用户，所以第一步永远是确认该用户是否真在连接中。注意用户名区分大小写，且通常为大写（如脚本里传入的 NCC40，查询时得写成 'NCC40'）：
select username, sid, serial#, status from v$session where username = 'NCC40';- 返回结果中
status为ACTIVE或INACTIVE都算“已连接”，只要存在记录就不能删 - 如果查不到，说明用户没连上——此时再报 ORA-01940，大概率是脚本/工具后台还挂着旧连接（比如 Navicat 未关闭的查询窗口、PL/SQL Developer 的未提交事务）
杀会话：用 alter system kill session 终止指定连接
拿到 sid 和 serial# 后，执行杀会话命令。格式固定，两个数字必须用单引号包裹、逗号不加空格：
-
alter system kill session '2309,2242';—— 这是唯一合法写法，'2309, 2242'或'2309,2242 '都会报错 - 执行后不会立刻消失，状态会变成
KILLED（不是KILL），此时会话正在清理资源，可能持续几秒到几十秒 - 别反复执行 kill —— 同一个会话被多次 kill 不会加速，反而可能让状态卡在
KILLED更久
验证会话是否真正释放：查 status 是否变为 KILLED
杀完别急着删用户，先确认会话已进入清理态：
select sid, serial#, status, program from v$session where username = 'NCC40';- 看到
status = 'KILLED'才算安全；如果仍是ACTIVE或INACTIVE，说明 kill 没生效（常见于权限不足或会话正执行长事务） - 若长时间卡在
KILLED，可查paddr并确认对应 OS 进程是否还活着：select spid from v$process where addr in (select paddr from v$session where username = 'NCC40');，再用ps -p <spid></spid>看进程是否存在
最后执行 drop user ... cascade
只有当 v$session 中完全查不到该用户名时，才能放心删：
-
drop user NCC40 cascade;——cascade必须加，否则会因存在对象报 ORA-01922 - 如果删完发现表空间还在，那是正常现象：
drop user不动表空间，需单独执行drop tablespace ... including contents and datafiles; - 脚本自动化时（如
cascade.sh），注意sqlplus输出可能含 ANSI 控制符或分页提示（less、more），容易把sid/serial#解析错——建议改用set pagesize 0 feedback off verify off压缩输出
最常被忽略的一点：杀会话后，客户端工具（Navicat / PL/SQL Dev）可能仍显示“已连接”，但实际连接已被 Oracle 中断。此时手动断开重连，或关掉整个工具再试，否则下次执行 drop 还会触发 ORA-01940。
