linux 删除用户会话,删除一个用户遇到的问题和解决

记录一次删除用户问题解决。

问题出现

这几天在进行数据库对象重建的工作，需要将数据库用户user删除重新创建。在确保开发团队下班离开之后，删除用户失败。

使用SQL命令行和EM进行删除，都报错。

SQL> drop user nbs;

drop user nbs

*

第1行出现错误:

ORA-01940:无法删除当前连接的用户

反复几次都报同样的错误。

问题分析

从错误提示上看，表示当前Oracle在尝试进行删除的时候，发现有用户nbs的session连接连入数据库。Oracle在删除user的时候，如果有当前用户连接，是不允许删除的。

此时所有的开发人员均已离开，不存在远程连接数据库的可能。

这样，如何确定是哪台机器还在连入呢？利用v$session视图。

SQL> select sid, serial#, username, machine, TERMINAL, program from v$session where username='NBS';

SID SERIAL# USERNAMEMACHINETERMINALPROGRAM

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

29 148 NBS WORKGROUP\WWW-0E6111DFF74 WWW-0E6111DFF74 plsqldev.exe

按照NBS用户搜索，果然发现连接用户信息。是位于WORKGROUP\ WWW-0E6111DFF74的计算机用户，开启了一个plsqldev.exe(PL/SQL Developer)程序。程序始终维持了一个连接在数据库。

猜测可能是开发人员没有及时关闭开发工具，使连接保持。

解决

了解原因，可以使用kill命令，将会话强制终止掉。

//kill session命令后两位参数分别为sid和Serial#，可以在v$session中找出；

SQL> alter system kill session '29,148';

System altered

这时，可以看到一个现象。如果我们再进行查询v$session，发现该会话信息还存在。

SQL> select sid, serial#, username, status from v$session where username='NBS';

SIDSERIAL# USERNAMESTATUS

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

29148 NBSKILLED

该条记录还存在，该session还存在。但是，status状态已经标志为KILLED，之前为ACTIVE和INACTIVE状态。这个时候，再进行删除。

SQL> drop user nbs;

User dropped

删除成功。但注意：此时session信息还存在，即使是killed。

SQL> select sid, serial#, username, status from v$session where username='NBS';

SIDSERIAL# USERNAMESTATUS

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

29148 NBSKILLED

说明：此时被kill掉的会话资源，并没有及时被实例后台进程PMON回收。那么，如果这个时候，被kill掉的会话要求通信怎么办。

下面是实验环境。

SQL> select count(*) from user_tables;

ORA-01017: invalid username/password: login denied;

结果是报错，说明连接已经断开，Process被迫中止。回头再看v$session.

SQL> select sid, serial#, username, status from v$session where username='NBS';

SIDSERIAL# USERNAMESTATUS

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

///会话信息被清理！！

这个小小的问题解决，告诉我们几个信息：

1、当用户存在连接数据库的会话是，Oracle是不允许对用户进行删除的；

2、使用alter system kill session进行会话清理时，只是对会话打上killed的标记，没有对客户端连入的Server Process做内存回收工作；更进一步实验，killed的过程，是将session的paddr地址指向了一个虚拟地址；

3、Kill之后，process与session的连接实际上已经被打断；

4、回收被kill的会话、Server Process资源，是由后台进程PMON完成，但是默认情况下，是需要等待一定时间的；

5、被kill掉之后，虽然资源没有回收，但是删除用户的操作可以完成了。可见Oracle对会话的疑虑可能在于事务和数据完整性；

6、被kill掉的会话，如果再次尝试连接，自身会受到报错；

7、再次连接的时候，会启动PMON，进行资源回收清理。至少将尝试连接的被kill会话资源回收；

PS：第二天联系开发人员，发现是因为关机错误引起一直没有关闭plsql developer。看来问题促进学习确实有效果！