<6> enqueue

    enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。

    A、ST enqueue 用于空间管理和字典管理的表空间的分配。利用LMT，或者试图对区域进行预分配，或者至少使下一个区域大于有问题的字典管理的表空间。
    B、HW enqueue 与段的高水位标记一起使用；手动分配区域可以避免这一等待。
    C、TX4 enqueue是最常见的enqueue 等待，通常是以下三个问题之一产生的结果:
    第一个问题是唯一索引中的重复索引，需要执行提交（commit）/回滚（rollback）操作来释放enqueue。
    第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址(rowid),所以当多个用户试图更新同一段时,你需要执行提交或回滚操作,以释放enqueue。
    第三个问题，也是最可能发生的问题是多个用户同时更新同一个块。如果没有自由的ITL槽，就会发生块级锁定。通过增大initrans 和/或maxtrans以允许使用多个ITL槽，或者增大表上的pctfree 值，就可以很轻松地避免这种情况。
    D、TM enqueue 在DML 期间产生，以避免对受影响的对象使用DDL。如果有外来关键字，一定要对它们进行索引，以避免这种常见的锁定问题。

    <7> log buffer space 日志缓冲空间

    当日志缓冲(log buffer)写入重做日志(redo log)的速度比LGWR 的写入速度慢，或者是当日志转换(log switch)太慢时，就会发生这种等待。为解决这个问题，可以增大日志文件的大小，或者增加日志缓冲器的大小，或者使用写入速度更快的磁盘。甚至可以考虑使用固态磁盘，因为它们的速度很高。

    <8> log file switch 日志文件转换

    有两种情况：

    A、log file switch (archiving needed)
    当日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，可增大日志文件和增加日志组，调整log_archive_max_processes

    B、log file switch (checkpoint incomplete)
    当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，通常是io有严重问题，可增大日志文件和增加日志组

    <9> log file sync 日志文件同步

    当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长（可能是因为一次log io size 太大），可调整 _log_io_size，结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突;放置日志文件于高速磁盘上

    <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.address
    and sid=<阻塞者的sid>

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

    <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.kgllkuse

    当然也可以直接从v$locked_objects中查看，但没有上面语句直观根据sid可以到v$process中查出pid，然后将其kill或者其它处理。