今天开发反馈说,执行某个程序update的时候hang住,查看了一下是个小表,只有3000多行数据。第一反应是有锁,把该实例的所有session kill后,执行update还是hang住,单独执行了下where条件后面的select很快。于是觉得应该是在2节点上还有lock,于是执行查询:
select * from gv$lock where id1=383105;
SQL> select * from gv$lock where id1=383105;
INST_ID ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
2 0000000110AF61B0 0000000110AF6210 1333 TM 383105 0 3 0 6819 2
果然,2节点上还有一个session持有锁。
连接到2节点,执行查询:
SQL> select sid,serial#,osuser from v$session where sid=1333;
SID SERIAL# OSUSER
1333 22559 6005821
alter system kill session '1333,22559';
杀了会话后,再查询,发现1333的session还存在:
SQL> select sid,serial#,osuser from v$session where sid=1333;
SID SERIAL# OSUSER
1333 22559 6005821
于是想从系统层kill,可是通过以下sql查询不到1333的spid
select p.pid,p.spid,s.sid,s.serial# from v$process p,v$session s where s.paddr=p.addr and s.sid=1333;
查询后发现,当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.此时v$process和v$session失去关联,进程就此中断。 然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间. 如果此时被Kill的process,重新尝试执行任务,那么马上会收到进程中断的提示,process退出,此时Oracle会立即启动PMON 来清除该session.这被作为一次异常中断处理.
根据以下sql找到之前的paddr:
select p.addr from v$process p where pid <> 1
minus
select s.paddr from v$session s;
07000107C8C050F8
07000107DCC19D88
根据v$process的addr找到spid:
select * from v$process where addr in ('07000107C8C050F8','07000107DCC19D88');
然后找到系统进程号,杀掉就好了。由于部分过程没有保留下执行结果,就只有记录下sql了。
oracle@cq2:] ps -ef|grep 8847870
oracle 8847870 1 3 Aug 06 - 734:23 ora_pz99_CQRPT2
oracle 10420652 13107576 0 11:11:01 pts/1 0:00 grep 8847870
[oracle@cq2:] ps -ef|grep 14221746
oracle 12583324 13107576 0 11:11:22 pts/1 0:00 grep 14221746
oracle 14221746 1 0 08:16:07 - 0:04 oracleCQRPT2 (LOCAL=NO)
[oracle@cq2:] kill -9 14221746
[oracle@cq2:] ps -ef|grep 14221746
oracle 12583046 13107576 0 11:12:11 pts/1 0:00 grep 14221746
测试过程还可以查看另一文章:https://www.cnblogs.com/kerrycode/p/4034231.html
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。