晚上开发人员告诉我，过程一编译就死机。查看v$session_wait有library cache pin等待。开发人员告诉我，编译前执行过这个过程，发现有误通过kill -9把JOB杀了,job是过程创建的。（并没有杀进程，而是杀的JOB）
根据几个系统内部表一步步的找到了阻塞编译的会话。
select a.sid,a.username,a.program,b.addr,b.KGLPNADR,b.KGLPNUSE,b.KGLPNSES,b.KGLPNHDL,
b.kGLPNLCK, b.KGLPNMOD, b.KGLPNREQ
from v$session a,x$kglpn b
where a.saddr=b.kglpnuse and b.kglpnhdl = 'C0000005C63EBD48' and b.KGLPNMOD<>0
kglpnhdl 的值是v$session_wait里的p1raw的值。根据查询结果，发现sid为7432的会话拥有这个handle。
查询这个会话的v$session_wait，存在一条记录，显示等待gc current multi block request。一般来说这个等待很短，可是我执行了N此查询，这个等待一直都存在，其实这个会话已经死掉了。
根据v$session,v$process找到操作系统进程，然后kill -9掉，问题解决。
还有一点不明白：一个过程执行过程中，这个时候有人编译，会产生library cache pin吗？
根据几个系统内部表一步步的找到了阻塞编译的会话。
select a.sid,a.username,a.program,b.addr,b.KGLPNADR,b.KGLPNUSE,b.KGLPNSES,b.KGLPNHDL,
b.kGLPNLCK, b.KGLPNMOD, b.KGLPNREQ
from v$session a,x$kglpn b
where a.saddr=b.kglpnuse and b.kglpnhdl = 'C0000005C63EBD48' and b.KGLPNMOD<>0
kglpnhdl 的值是v$session_wait里的p1raw的值。根据查询结果，发现sid为7432的会话拥有这个handle。
查询这个会话的v$session_wait，存在一条记录，显示等待gc current multi block request。一般来说这个等待很短，可是我执行了N此查询，这个等待一直都存在，其实这个会话已经死掉了。
根据v$session,v$process找到操作系统进程，然后kill -9掉，问题解决。
还有一点不明白：一个过程执行过程中，这个时候有人编译，会产生library cache pin吗？
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22034023/viewspace-667521/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
想后台执行一段代码，请教怎么写？
请登录后发表评论
登录
全部评论
