10g 上的Library Cache Pin的解决办法

   今天开发要编绎一个存储过程，我开始编绎时发现一直无法成功，查了一下v$session_wait发现有一个Library Cache Pin,估计是有人在用它了，用了9i中查找锁隹这个procedure的holder的语句，发现在10g库无法找到x$kglob，x$kglpn 以前写好的SQL在10g 上是没希望了，想起来10g可以通过v$session 中可以找到谁blocking 了我，我找到一下我自己的会话，果然看到BLOCKING_SESSION有一个3655,WAIT_CLASS还是哪个字段记不清了中有Library Cache Pin显示，查出sql，和开发确认之后，kill了这个session ，发现只是标记为killed, 找到spid，在os kill-9 ,总算把它清理了，再编译，很快完成。

    10g中library cache pin查找原因相比9i还是容易了很多.

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

转载于:http://blog.itpub.net/10834762/viewspace-589338/