1,首先,执行一个比较消耗资源的sql语句
测试语句如下:
select count(*) from all_objects,all_objects;
2,记忆中,v$session_longops中会记录执行时间超过6s的sql,下面去验证记忆(此时我已经午睡醒了)
SQL> select username,sid,opname,
2 round(sofar*100 / totalwork,0) || '%' as progress,
3 time_remaining,sql_text
4 from v$session_longops , v$sql
5 where username='SCOTT';
no rows selected
对此,表示记忆出错了,然后询问了百科全书-杨老师,大师的解释如下:
v$session_longops中纪录的是单步超过6s的操作,不是执行时间超过6s的sql。
比如,你的一个sql,如果扫描一个表超过6s,那么会被纪录;
但是如果你的sql总时间超过6s,访问单表和表链接的单步时间不超过6s也不会被纪录。
3,记忆出错了,就按照现在的理解来做吧,查看v$session获取sid serial#
SQL> SELECT SERIAL#,SID,USERNAME,STATUS,SQL_ID,PADDR
2 FROM V$SESSION
3 WHERE USERNAME='SCOTT';
SERIAL# SID USERNAME STATUS SQL_ID PADDR
---------- ---------- ---------- -------- ------------- ----------------
161 53 SCOTT ACTIVE 6jm6k9uw8u6cp 00000000C2520A78
4,数据库中杀掉这个session
SQL> ALTER SYSTEM KILL SESSION '53,161';
System altered.
5,再次查看v$session
SQL> SELECT SID,SERIAL#,USERNAME,STATUS,SQL_ID FROM V$SESSION WHERE USERNAME='SCOTT';
SID SERIAL# USERNAME STATUS SQL_ID
---------- ---------- ---------- -------- -------------
53 161 SCOTT KILLED 00000000C25B0038
状态竟然是一个killed,再次执行看看
SQL> SELECT SID,SERIAL#,USERNAME,STATUS,SQL_ID FROM V$SESSION WHERE USERNAME='SCOTT';
no rows selected
这次没有了,所以,猜测,killed状态时,资源没有得到释放。
看了看公司老大博客中,关于kill session的介绍,以及潇湘隐者的博客,得出以下结论:
6,彻底杀死,释放资源
很多时候,杀死一个会话,是因为我们想要释放这个会话所占用的资源,但是像上面说的,kill session 并没有马上释放资源。
如果要立马释放资源,可以从操作系统层面上,kill -9 spid来实现
SELECT b.sid,
b.username,
b.serial#,
spid,
paddr,
sql_text,
b.machine
FROM v$process a, v$session b, v$sqlarea c
WHERE a.addr = b.paddr
AND b.sql_hash_value = c.hash_value
and sql_text not like '%FROM v$process a, v$session b, v$sqlarea c%'
这样就可以从操作系统上面,kill -9 了。
kill-9 会立即杀死会话,并且立即释放资源。
测试语句如下:
select count(*) from all_objects,all_objects;
2,记忆中,v$session_longops中会记录执行时间超过6s的sql,下面去验证记忆(此时我已经午睡醒了)
SQL> select username,sid,opname,
2 round(sofar*100 / totalwork,0) || '%' as progress,
3 time_remaining,sql_text
4 from v$session_longops , v$sql
5 where username='SCOTT';
no rows selected
对此,表示记忆出错了,然后询问了百科全书-杨老师,大师的解释如下:
v$session_longops中纪录的是单步超过6s的操作,不是执行时间超过6s的sql。
比如,你的一个sql,如果扫描一个表超过6s,那么会被纪录;
但是如果你的sql总时间超过6s,访问单表和表链接的单步时间不超过6s也不会被纪录。
3,记忆出错了,就按照现在的理解来做吧,查看v$session获取sid serial#
SQL> SELECT SERIAL#,SID,USERNAME,STATUS,SQL_ID,PADDR
2 FROM V$SESSION
3 WHERE USERNAME='SCOTT';
SERIAL# SID USERNAME STATUS SQL_ID PADDR
---------- ---------- ---------- -------- ------------- ----------------
161 53 SCOTT ACTIVE 6jm6k9uw8u6cp 00000000C2520A78
4,数据库中杀掉这个session
SQL> ALTER SYSTEM KILL SESSION '53,161';
System altered.
5,再次查看v$session
SQL> SELECT SID,SERIAL#,USERNAME,STATUS,SQL_ID FROM V$SESSION WHERE USERNAME='SCOTT';
SID SERIAL# USERNAME STATUS SQL_ID
---------- ---------- ---------- -------- -------------
53 161 SCOTT KILLED 00000000C25B0038
状态竟然是一个killed,再次执行看看
SQL> SELECT SID,SERIAL#,USERNAME,STATUS,SQL_ID FROM V$SESSION WHERE USERNAME='SCOTT';
no rows selected
这次没有了,所以,猜测,killed状态时,资源没有得到释放。
看了看公司老大博客中,关于kill session的介绍,以及潇湘隐者的博客,得出以下结论:
当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.
此时v$process和v$session失去关联,进程就此中断.
然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间.
如果此时被Kill的process,重新尝试执行任务,那么马上会收到进程中断的提示,process退出,此时Oracle会立即启动PMON
来清除该session.这被作为一次异常中断处理.
6,彻底杀死,释放资源
很多时候,杀死一个会话,是因为我们想要释放这个会话所占用的资源,但是像上面说的,kill session 并没有马上释放资源。
如果要立马释放资源,可以从操作系统层面上,kill -9 spid来实现
SELECT b.sid,
b.username,
b.serial#,
spid,
paddr,
sql_text,
b.machine
FROM v$process a, v$session b, v$sqlarea c
WHERE a.addr = b.paddr
AND b.sql_hash_value = c.hash_value
and sql_text not like '%FROM v$process a, v$session b, v$sqlarea c%'
这样就可以从操作系统上面,kill -9 了。
kill-9 会立即杀死会话,并且立即释放资源。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30123160/viewspace-2050834/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30123160/viewspace-2050834/