生产环境library cache lock/pin解决方案

     今天上午巡检数据库的时候发现数据库出现近55个session在library cache lock、library cache bin上等待。经过分析，发现有8个session在对数据库对象进行编译或重编译，从9月7日(从周末开始)就开始对数据库对象进行编译或重编译，导致相关的依赖对象的数据库操作被阻塞，相关依赖对象的数据库操作具体有select ,dml等操作，均被阻塞进程，以至于出现上述等待事件，被阻塞的session为47个。

     下面的这个过程是解决的具体操作：

55个session在等待library cache lock、library cache bin

SQL> SELECTdistinct s.sid, kglpnmod"Mode", kglpnreq "Req", SPID "OS Process"

  FROM v$session_wait w, x$kglpn p, v$session s, v$process o

  WHERE p.kglpnuse = s.saddr

  AND p.kglpnhdl = w.p1raw

  and w.event like '%library cache%'

  and s.paddr = o.addr;  2    3    4    5    6 

       SID       Mode        Req OS Process

---------- ---------- ---------- ------------

       834          3          0 103856

       225          0          2 198538

       894          0          2 132230

       739          3          0 257234

        98          0          2 219290

        88          0          2 270956

       483          0          2 248826

       236          0          2 80360

       728          0          2 57178

       789          0          2 83764

       889          3          0 83658

       142          0          2 32746

       789          0          2 83764

       709          0          2 133414

       770          0          2 119300

       497          0          2 174704

        76          0          2 100064

       688          0          2 193496

       199          0          2 270842

       130          0          2 222368

       421          0          2 256196

       402          0          2 199614

       110          3          0 155564

       356          0          2 245854

       758          3          0 203856

       722          0          2 124620

       457          0          2 221432

       709          0          2 133414

       449          0          2 168288

       117          0          2 217924

       550          3          0 192620

       590          0          2 150370

       582          3          0 83046

       429          0          2 64810

       910          0          2 168536

       29          0          2 277628

       321          0          2 196554

       497          0          2 174704

       709          0          2 133414

       142          0          2 32746

       789          0          2 83764

       889          3          0 83658

       236          0          2 80360

       728          0          2 57178

       98           0          2 219290

       268          0          2 118170

       894          0          2 132230

       505          3          0 170336

       616          0          2 223686

上面的sql就在shared pool共享池检索出哪些session占用了被依赖资源的句柄，需要做的就是kill掉这些持有对象句柄的进程。

  下面这个sql就至找出持有锁的进程：

SQL> SELECT distinct s.sid, kglpnmod"Mode", kglpnreq "Req", SPID "OS Process"

  FROM v$session_wait w, x$kglpn p, v$session s, v$process o

  WHERE p.kglpnuse = s.saddr

  AND p.kglpnhdl = w.p1raw

  and w.event like '%library cache%'

  and s.paddr = o.addr

  and kglpnmod =3;

  2    3    4    5    6    7 

       SID       Mode        Req OS Process

---------- ---------- ---------- ------------

       834          3          0 103856

       505          3          0 170336

       739          3          0 257234

       889          3          0 83658

       758          3          0 203856

       110          3          0 155564

       550          3          0 192620

       582          3          0 83046

就是上面的8个进程占用了句柄，103856、170336、257234、83658、203856、155564、192620、83046

kill 掉这些进程：

oracle@DBHIS02>kill -9 103856

oracle@ DBHIS02>kill -9 170336

oracle@ DBHIS02>kill -9 257234

oracle@ DBHIS02>kill -9 83658

oracle@ DBHIS02>kill -9 203856

oracle@ DBHIS02>kill -9 155564

oracle@ DBHIS02>kill -9 192620

oracle@ DBHIS02>kill -9 83046

kill掉之后，阻塞的8个session释放了锁资源，被阻塞的47个session获得了资源，进行正常的资源请求。