如果一个过程正在执行，这个时候编译这个过程，会产生library cache pin

最新推荐文章于 2025-12-30 19:07:24 发布

转载最新推荐文章于 2025-12-30 19:07:24 发布 · 79 阅读

文章标签：

#数据库

本文解决了一个因编译过程导致的数据库死锁问题。通过查询v$session和x$kglpn表定位到持有特定handle的会话，并最终通过kill操作解决了死锁情况。

晚上开发人员告诉我，过程一编译就死机。查看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吗？

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-667521/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-667521/