latch contention
 
    我们已发现oracle希望latch总是短暂持有。如果对于任何latch使用并未采用此种方式，很可能发生了latch contention.
当一个latch被一个进程持有，但同时多个进程也需要它，就产生了latch contention.直至积累下来的需要皆处理完，等待进程
必须竞争这个latch.这样导致无效使用cpu time,甚至对性能造成相当大的影响.
    竞争某个特定的latch所产生的结果，通过频度，持续时间及latch contention episode的强度来衡量它.v$latch的sleep1及sleep2
列的sleep count历史柱状图可以对此进行评估.注意：如果sleep cycles重复次数多于4次，不会保存它的统计信息.sleep5-sleep11保存下
仅是为了兼容oracle7.3之前的版本.
    sleep counts的柱状图，可以确定效力（或无效），以此减少对于latch contention.但是sleeps/gets值为latch tuning提供一个很好的参考.



latch levels
   oracle进程需要同时持有许多latch。因此，会出现这种可能性：latching deadlocks问题，持有latch a的进程和持有latch b的进程，这两个进程都在spinning
等待另一个latch.oracle为了避免出现这种情况，latches始终以定义好的顺序获取，当需要多个latch时。为了支持这种情况，oracle中的每个latch有一个位于15之间的level,每个进程会专门为此维护一个2-byte的位图，以此表示这个进程
目前持有latch的level是多少.当一个进程尝试以乐观方式get a latch时，会检查一下确保这个latch没有以相同的level被其它进程占有，或者更高级别持有.一般来讲，如果违犯这种机制，ora-600[504]错误会抛出.
  (注：但是这种latch level 规则有时可以适量放松，允许两个library cache child latches同时被持有)
对于像redo allocation latch(level 6)高级别latch的contention,会加剧对于像cache buffers chains latches（oracle8.1是level1)低级latch的contention.会发生这个是因为需要高级latch的进程必须等待，当它持有一个低级latch时。因此，
低级latch会比正常情况下持有时间更长。v$latch的 waits_holding_latch就是最好的指示灯。这个统计表示当它持有这种latch，等待的次数.这些等待次数也包含，但不限于，等待一个高级的latch.比如，等待cache buffers chains latches产生的latch 统计信息，
包含了sleeps，当尝试获取redo allocation latch时.但是，它也包含其它一些如log buffer space waits的等待次数(waits).这些waits应该首先被考虑。因此，正常情况下，根据latch level以降序方式考虑这些latch contention问题是最明智的。



no-wait mode 不等待模式
   它适用于：oracle已持有一个latch,并且想以同级或低级得到另一个latch.乐观等待模式不能用于这种情况，因为需要防止出现死锁。这种情况下，oracle以no-wait mode请求一个latch,只要这对latches已同级模式持有.如果no-wait 请求成功，就不会出现死锁，这样最好。但如果请求失败，
就会出现这个进程继续坚持请求这个latch，进而生了deadlock.相反，这个进程会release所有的高级latch(已持有的），让出cpu资源，然后马上再次以正常的级别次数请求latch.
    redo copy latch就属于这种特殊情况。no-wait mode用于latch get的大多数情况，因为oracle用它们可以保护把数据拷贝到log buffer这个动作.如果请求redo copy latch失败，oracle会在另一个redo copy latch实现它。乐观等待模式只用于no-wait mode请求所有其它的redo copy latch失败，
才会用到乐观等待模式.这是一种正常的等待情况，当持有redo copy latches时，比如竞争高级的latch,通过加大_log_simultaneous_copies不会起到什么作用.
除了redo copy latch外，oracle有时会以no-wait mode get一些类型的latch.对于所有其它类型的latch,v$latch immediate_gets和immediate_misses始终为0.

    从性能角度出发，immediate misses并不表示具有性能问题。如果满足乐观等待请求的条件，放弃的latch被重新利用或获取，这时immediate miss的成本就不会显得不过分.
但是，如果发现对于其它一些latch出现竞争,那么immediate misses增加了对于这些latch的负荷,就会加剧这种情况.因此，调优任何latch，你应该想法减少immediate misses和sleeps.但是，不要失去过多的sleep(相对于immediate misses)，除非是对于一些高级的latch等待太多.



latch cleanups
    现实存在oracle的进程有时会意外死亡，或者当它持有一个latch时死亡.oracle pmon进程的工作就是检测哪些用户进程意外死亡，并实行清除工作.在这个清除工作过程中，pmon会首先执行latch cleanup.latch cleanup先处理完所有新增的已故进程，然后开始rollback未提交的事务.

    latch cleanup并不仅仅是一个free latch的问题。latch是用来操作数据结构的，如果一个持有latch的进程意外死亡，很可能latch所保护的数据结构可能会出现不一致的情况。为了支持latch recovery,持有latch的进程为了操作一个数据结构，先写一条数据操作的记录信息到对应于这个latch的latch recovery area中，然后
实行操作(操作数据结构）.pmon的工作不仅仅是free latch,还要恢复被latch保护的数据结构.如果latch recovery需要进行或正在操作之中，我们说这个latch处于flux.

     但是，因为pmon正常情况下是每3 second唤醒一次，oracle也有另一种发起latch clearup的方法.如果一个进程多次重复依旧得不到latch,它将实行一个latch activity test,分析是否有必要进行latch cleanup.如果在5 centisecons的时间内，没有任何latch的活动，进程就会通知pmon,pmon将检查持有latch的进程是否死亡，及有无必要被清除.
当一个进程正在执行一个latch activity test时，或者等待pmon进程检查持有latch的进程，v$session_wait显示一个latch activity wait的相关信息。


   wait parameters(latch activity waits)
参数                                    描述
p1                                      请求latch的sga address
p2                                      latch类型
p3                                      0表示latch activity test。否则，pmon会检查可能已故持有latch的进程号


  如果latch contention伴有大量latch activity waits,这两种问题的原因，可能是os的调度问题（它阻止latch持有者快速方式free latch)