关于Oracle中Session的干掉问题。

原创 2004年09月17日 11:25:00

我们知道,在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:

alter system kill session 'sid,serial#' ;

 

被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.


我们发现当一个session被kill掉以后,该session的paddr被修改,如果有多个session被kill,那么多个session
的paddr都被更改为相同的进程地址:

 

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR           SID    SERIAL# PADDR    USERNAME                       STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C         11        314 542B70E8 EYGLE                          INACTIVE
542E5044         18        662 542B6D38 SYS                            ACTIVE


SQL> alter system kill session '11,314';

System altered.

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR           SID    SERIAL# PADDR    USERNAME                       STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C         11        314 542D6BD4 EYGLE                          KILLED
542E5044         18        662 542B6D38 SYS                            ACTIVE


SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR           SID    SERIAL# PADDR    USERNAME                       STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C         11        314 542D6BD4 EYGLE                          KILLED
542E2AA4         14        397 542B7498 EQSP                           INACTIVE
542E5044         18        662 542B6D38 SYS                            ACTIVE

SQL> alter system kill session '14,397';

System altered.

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR           SID    SERIAL# PADDR    USERNAME                       STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C         11        314 542D6BD4 EYGLE                          KILLED
542E2AA4         14        397 542D6BD4 EQSP                           KILLED
542E5044         18        662 542B6D38 SYS                            ACTIVE


在这种情况下,很多时候,资源是无法释放的,我们需要查询spid,在操作系统级来kill这些进程.

但是由于此时v$session.paddr已经改变,我们无法通过v$session和v$process关联来获得spid

那还可以怎么办呢?

我们来看一下下面的查询:

 

 

 

  SQL> SELECT s.username,s.status,
  2  x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
  3  decode(bitand (x.ksuprflg,2),0,null,1)
  4  FROM x$ksupr x,v$session s
  5  WHERE s.paddr(+)=x.addr
  6  and bitand(ksspaflg,1)!=0;


USERNAME                       STATUS   ADDR       KSLLAPSC   KSLLAPSN KSLLASPO       KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
                                        542B44A8          0          0                       0
                               ACTIVE   542B4858          1         14 24069                 0    1
                               ACTIVE   542B4C08         26         16 15901                 0    1
                               ACTIVE   542B4FB8          7         46 24083                 0    1
                               ACTIVE   542B5368         12         15 24081                 0    1
                               ACTIVE   542B5718         15         46 24083                 0    1
                               ACTIVE   542B5AC8         79          4 15923                 0    1
                               ACTIVE   542B5E78         50         16 24085                 0    1
                               ACTIVE   542B6228        754         15 24081                 0    1
                               ACTIVE   542B65D8          1         14 24069                 0    1
                               ACTIVE   542B6988          2         30 14571                 0    1

USERNAME                       STATUS   ADDR       KSLLAPSC   KSLLAPSN KSLLASPO       KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
SYS                            ACTIVE   542B6D38          2          8 24071                 0
                                        542B70E8          1         15 24081               195 EV
                                        542B7498          1         15 24081               195 EV
SYS                            INACTIVE 542B7848          0          0                       0
SYS                            INACTIVE 542B7BF8          1         15 24081               195 EV

16 rows selected.
          

 

 

我们注意,红字标出的部分就是被Kill掉的进程的进程地址.

简化一点,其实就是如下概念:

SQL> select p.addr from v$process p where pid <> 1
2 minus
3 select s.paddr from v$session s;

ADDR
--------
542B70E8
542B7498

 

Ok,现在我们获得了进程地址,就可以在v$process中找到spid,然后可以使用Kill或者orakill在系统级来杀掉这些进程.

实际上,我猜测:

当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.

此时v$process和v$session失去关联,进程就此中断.

然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间.

如果此时被Kill的process,重新尝试执行任务,那么马上会收到进程中断的提示,process退出,此时Oracle会立即启动PMON
来清除该session.这被作为一次异常中断处理.

 

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

关于本文题我在工作中的心得:

1。用自己脚本conn查看当前被阻塞或阻塞的sid,#serial

2。用alter system kill session 'sid,#serial';

3。上一步可能会出现错误,没关系,只是打个killed标志。

4。用以下语句查看一下,打上killed标志session.

select saddr,sid,serial#,paddr,username,status from v$session where username is not null order by 6
/

5。以 sqlplus sys/change_on_install@orcl登陆。

执行:

 select s.username,s.status,x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
decode(bitand (x.ksuprflg,2),0,null,1)
from x$ksupr x, v$session s
where s.paddr(+)=x.addr
and bitand(ksspaflg,1)!=0
order by 2
/

6。查出所有的打上killed标志,或者status为空的ADDR的值。

7。

select SPID,TERMINAL,PROGRAM,USERNAME from v$process where ADDR = '00000004008DDFF8' or ADDR=' ' ..........

8。查出所有的SPID值。

9。在Unix数据库服务器下,以root用户登陆,ps -ef |grep spid,确认一下需要杀掉的进程。

10。如果是orcleorcl等的一般连接进程,全部用kill -9 sid杀掉。

11。阻塞问题搞定。

干掉状态:从session到token

1 美好的旧时光 我经常怀念三十年前那美好的旧时光, 工作很轻松, 生活很悠闲。 上班的时候偶尔有些HTTP的请求发到我这里, 我简单的看一下, 取出相对应的...
  • GarfieldEr007
  • GarfieldEr007
  • 2017年03月27日 19:54
  • 876

Oracle 杀死session的方法

有时数据库有些session产生死锁托慢整个数据库,需要找出那个进程然后kill掉.在sybase中, 结合sp_who 和 kill sid就可以了.在oracle中也有类似的方法:首先是找出要杀死...
  • nvd11
  • nvd11
  • 2013年04月02日 00:56
  • 937

如何查看oracle当前的session连接数

怎样查看oracle当前的连接数呢?只要用下面的SQL语句 #查看当前不为空的连接 select * from v$session where username is not null; ...
  • huluedeai
  • huluedeai
  • 2015年04月02日 19:59
  • 1798

干掉状态:从session到token

1 美好的旧时光 我经常怀念三十年前那美好的旧时光, 工作很轻松, 生活很悠闲。 上班的时候偶尔有些HTTP的请求发到我这里, 我简单的看一下, 取出相对应的html文档,图片,发回...
  • jiangzhexi
  • jiangzhexi
  • 2017年06月14日 09:57
  • 380

Oracle的关于session的销毁资源回收问题的解决方案

在Oracle中kill一个session采用如下语句:alter system kill session 'sid,serial#' ; 通过以下实验我们发现kill session并没有真正...
  • u010719917
  • u010719917
  • 2016年12月02日 15:03
  • 1068

干掉状态:从session到token

1 美好的旧时光 我经常怀念三十年前那美好的旧时光,工作很轻松,生活很悠闲。 上班的时候偶尔有些HTTP的请求发到我这里,我简单的看一下,取出相对应的html文档,图片,发回去就可以...
  • jek123456
  • jek123456
  • 2017年03月22日 18:47
  • 142

oracle dblink造成远程数据库session过多

现场报网公司数据库连不上,先检查了下数据库processes=1500,session=2200.我觉得很大啊,这个数据库没有几个人用。    查看v$session中的session最多是哪个mac...
  • guogang83
  • guogang83
  • 2015年06月09日 17:58
  • 2839

oracle 中dblink的session不能自动释放

Oracle跨数据库连接dblink的session不能自动释放。 环境: 远数据库A  目标数据库B 目的:在B上建立dblink 连接到A,在B中创建视图,查询A的数据. 问题: 由于B...
  • XMM_1030
  • XMM_1030
  • 2015年09月25日 23:57
  • 3810

oracle 中查询占用session最多的进程

在故障发生时,尝试用下面的语句抓取数据库引起故障的点。 /********************************************************************...
  • saming2010
  • saming2010
  • 2013年08月29日 15:34
  • 611

介绍oracle的restrict状态

在Oracle启动时,有三种状态可以选择:restrict,force,EXCLUSIVE.这篇文章,介绍一下关于restrict状态。  1. startup restrict:     约束方...
  • techsupporter
  • techsupporter
  • 2016年08月22日 22:46
  • 767
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于Oracle中Session的干掉问题。
举报原因:
原因补充:

(最多只允许输入30个字)