latch

<10> library cache pin [游标上]
该事件通常是发生在先有会话在运行PL/SQL,VIEW,TYPES等object时,又有另外的会话执行重新编译这些object,即先给对象加上了一个共享锁,然后又给它加排它锁,这样在加排它锁的会话上就会出现这个等待。P1,P2可与x$kglpn和x$kglob表相关 
X$KGLOB (Kernel Generic Library Cache Manager Object) 
X$KGLPN (Kernel Generic Library Cache Manager Object Pins) 
-- 查询X$KGLOB,可找到相关的object,其SQL语句如下 
(即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连) 
select kglnaown, kglnaobj
  from X$KGLOB
 where KGLHDADR =
       (select p1raw from v$session_wait where event = 'library cache pin')
-- 查出引起该等待事件的阻塞者的sid 
select sid
  from x$kglpn, v$session
 where KGLPNHDL in (select p1raw
                      from v$session_wait
                     where wait_time = 0
                       and event like 'library cache pin%')
   and KGLPNMOD <> 0
   and v$session.saddr = x$kglpn.kglpnuse
   
-- 查出阻塞者正执行的SQL语句 
select sid, sql_text
  from v$session, v$sqlarea
 where v$session.sql_address = v$sqlarea.add
 
<11> library cache lock 
该事件通常是由于执行多个DDL操作导致的,即在library cache object上添加一个排它锁后,
又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可通过到基表x$kgllk中查找其对应的对象。 
-- 查询引起该等待事件的阻塞者的sid、会话用户、锁住的对象 
select b.sid, a.user_name, a.kglnaobj
  from x$kgllk a, v$session b
 where a.kgllkhdl in (select p1raw
                        from v$session_wait
                       where wait_time = 0
                         and event = 'library cache lock')
   and a.kgllkmod <> 0
   and b.saddr = a.kgllkuseress
   and sid = < 阻塞者的sid >
   
当然也可以直接从v$locked_objects中查看，但没有上面语句直观根据sid可以到v$process中查出pid，
然后将其kill或者其它处理

这样,就可找到"library cache pin"等待的根源，从而解决由此引起的性能问题

<3> free buffer waits 释放缓冲区等待 (增大DB_CACHE_SIZE,加速检查点,调整代码) 
这种等待表明系统正在等待内存中的缓冲，因为内存中已经没有可用的缓冲空间了。如果所有SQL 都得到了调优，
这种等待可能表示你需要增大DB_BUFFER_CACHE。释放缓冲区等待也可能表示不加选择的SQL 导致数据溢出了带有索引块的缓冲存储器，
没有为等待系统处理的特定语句留有缓冲区。
这种情况通常表示正在执行相当多数量的DML（插入／更新／删除），
并且数据库书写器(DBWR)写的速度不够快，缓冲存储器可能充满了相同缓冲器的多个版本，从而导致效率非常低。
为了解决这个问题，可能需要考虑增加检查点、利用更多的DBWR 进程，或者增加物理磁盘的数量。


<4> buffer busy waits 缓冲区忙等待 (BUFFER热块) 
   这是为了等待一个以非共享方式使用的缓冲区，或者正在被读入缓冲存储器的缓冲区。缓冲区忙等待不应大于1%。检查缓冲等待统计部分（或V$WAITSTAT）: 
A、如果等待处于字段头部，应增加自由列表（freelist）的组数，或者增加pctused到pctfree之间的距离。 
B、如果等待处于回退段（undo）头部块，可以通过增加回滚段(rollback segment)来解决缓冲区的问题； 
C、如果等待处于回退段（undo）非头部块上，就需要降低驱动一致读取的表中的数据密度,或者增大DB_CACHE_SIZE； 
D、如果等待处于数据块，可以将数据移到另一数据块以避开这个"热"数据块、增加表中的自由列表或使用LMT表空间； 
E、如果等待处于索引块，应该重建索引、分割索引或使用反向键索引。 
为了防止与数据块相关的缓冲忙等待，也可以使用较小的块：
在这种情况下，单个块中的记录就较少，所以这个块就不是那么"繁忙"。
在执行DML(插入/更新/删除)时,Oracle DBWR就向块中写入信息，
包括所有对块状态"感兴趣"的用户(感兴趣的事务表，ITL)。为减少这一区域的等待，
可以增加initrans，这样会在块中创建空间，从而使你能够使用多个ITL槽。你也可以增加该块所在表中的pctfree(当根据指定的initrans 建立的槽数量不足时，这样可以使ITL 信息数量达到maxtrans 指定的数量）。