执行删除用户报错

SQL> drop user fork;

ERROR at line 1:

ORA-01940: cannot drop a user that is currently connected

于是按照提示， 根据以下语句检查当前用户相关会话：

select saddr, sid, serial#, paddr, username, status

  from v$session

 where username =' fork' order by SID desc;

SADDR             SID  SERIAL#  PADDR           USERNAME      STATUS

00000004637DA8F0  7514  60952 0000000442C22390  FORK INACTIVE

0000000443662508  5860  8781  0000000422B53420  FORK  INACTIVE

00000003A36875F8  5667  8491  0000000442C16D60  FORK  INACTIVE

00000003A3616378  5331  18362 00000003A2CA8498  FORK  INACTIVE

00000003E34DC8A0  4923  23329 00000003C2B83148  FORK  INACTIVE

0000000423453B90  4851  11801 0000000422B4D0C0  FORK  INACTIVE

00000003A348A2B8  4155  24513 00000003A2CA10A8  FORK  INACTIVE

0000000423184B58  2714  13967 0000000422B6F350  FORK  INACTIVE

查看相关资料对 v$session 对status的解释如下：

《Oracle Database reference》说明：

• ACTIVE - Session currently executing SQL

• INACTIVE - Session which is inactive and either has no configured limits or has not yet exceeded the configured limits

• KILLED - Session marked to be killed

• CACHED - Session temporarily cached for use by Oracle*XA

• SNIPED - An inactive session that has exceeded some configured limits (for example, resource limits specified for the resource manager consumer group or idle_time specified in the user's profile). Such sessions will not be allowed to become active again.

（1）active 处于此状态的会话，表示正在执行，处于活动状态。

            官方文档说明：

            Any session that is connected to the database and is waiting for an event that does not belong to the Idle wait class is considered as an active session.

（2）killed 处于此状态的会话，被标注为删除，表示出现了错误，正在回滚。

            当然，也是占用系统资源的。还有一点就是，killed的状态一般会持续较长时间，

            而且用windows下的工具pl/sql developer来kill掉，是不管用的，要用命令：alter system kill session 'sid,serial#' ;

（3）inactive 处于此状态的会话表示不是正在执行的

              该状态处于等待操作(即等待需要执行的SQL语句)，通常当DML语句已经完成。 

              但连接没有释放，这个可能是程序中没有释放，如果是使用中间件来连接的话，也可能是中间件的配置或者是bug 导致。

              inactive对数据库本身没有什么影响，但是如果程序没有及时commit，那么就会造成占用过多会话。容易是DB 的session 达到极限值。

              问了几个朋友，他们的做法是不处理inactive 状态的session， 如果达到了session 的最大值， 就增加processes 和 sessions 参数。 

              如果kill inactive session 可能会到中间件有影响。 具体中间件这块我也不太熟，等以后弄清楚了再说。

使用 alter system kill session 'sid,serial#' 杀掉会话，

奇怪的是将 sid、serial# 代入语句执行后，会话依旧存在。

于是想到从OS层面上进行干预。

通过 v$process 定位对应的spid

select addr,pid,sosid,spid,program

  from v$process

 where addr in ('0000000442C22390',

                '0000000422B53420',

                '0000000442C16D60',

                '00000003A2CA8498',

                '00000003C2B83148',

                '0000000422B4D0C0',

                '0000000462B48F78',

                '00000003A2CA10A8',

                '0000000422B6F350');

--------------------------------------------------------                

ADDR              PID SOSID   SPID    PROGRAM

0000000462B48F78  513 189377  189377  oracle@sxrsj01 (W00M)

00000003C2B83148  525 18714   18714   oracle@sxrsj01

00000003A2CA10A8  813 29901   29901   oracle@sxrsj01

由于是rac环境，确定该进程存在哪个节点后进行处理

ps -ef |grep spid

kill -9 spid

处理完成后，处理 inactive 的会话消息，但等待一会时间后会出现新的session，

猜测可能是中间件连接池的原因。

将该用户的所有角色、权限收回，不允许打开新会话。

revoke xxx from FORK;   

最后重新执行，成功删除。

drop user fork cascade;

参考资料：

《Reference 12c Release 2 (12.2) E85634-02》

https://blog.csdn.net/tianlesoftware/article/details/6539297

https://blog.csdn.net/bisal/article/details/928263