当一个会话release 一个enqueue lock,它会检查lock request和conversion queues(对于某个资源），如果可能，给下个进程发送通知，你可以持有这个资源的锁了.

  进程在等待前，也会设置一个alarm,这个进程会发生enqueue wait.超时间隔或期间依赖于资源的类型。对于大多数入队，入队等待超时是3秒.

  当尝试请求一次enqueue lock时，如果发生连续的等待，会在系统或会话中记录下来。但是，v$sysstat的入队等待统计仅仅是递增。请注意：v$sysstat入队超时信息并不表示
入队等待超时次数。相反，当入队请求或入队转变被中断时，这个统计信息值会递增时。这可能与一个分布式事务超时有关，但通常与在no-wait mode请求锁有关.

          
         
          fixed array free lists
   每个oracle固定队列的free slots在一个自由列表free list中维护。对于这种队列，free lists 头部的指针会指向这个队列的其中free slots之一.相反，这个slot,会有一个指针指向自由列表下一个free slot。
  
   free slots经常从free list的头部得到，经常返回free list的头部。这意味着free list的尾部经常不会用，当有必要时，hwm仅仅先前进展.


   如果v$sysstat发现大量入队等待，通过x$ksqst得到或发现对于某种资源等待的故障或问题.


   大多建议增加enqueue_resources减少入队等待。但请注意这个没有作用。oracle将会发生ora-52或53错误，如果在enqueue resource(或enqueue locks fixed array)中找不到free slot.除于以外，
配置enqueue_resource和_enqueue_locks起效不明显.
   v$resource_limit可以调整enqueue_resources和_enqueue_locks，确认你不会用完array的slots。因为array的slots会分别采用72bytes和60bytes的次序.我想在曾经最大利用的空间之上维护或占用20%的空间.






   deadlock detection

    oracle自动实现enqueue locking死锁的死锁检测.如果发生一次入队等待超时，就会产生死锁检测，如果所需要的资源类型与死锁关系比较大，如果锁的状态没有改变。

    如果发现死锁，会话只是终止或rollback当前的语句，以打破死锁。注意，仅仅是当前语句的rollback，没必要整个事务.oracle会在每个语句开始时，设置一个隐式保存点，叫作默认保存点,
只是rollback到这个保存点。
    会话发现一个死锁时，会产生ora-60错误。v$sysstat会记录发生了多少次enqueue deadlock。
 



blocking locks
   有多种诊断blocking lock情况的方式,正常处理是通过杀掉产生麻烦的会话.


   blocking locks基本是tx(transaction) locks on tm(table) locks。


   一些应用开发者用select for update nowait来避免blocking locks.但是如果采用这种方式允许用户交涉,得到一个sub-exclusive的锁和release锁,此时会产生更为细微的lock。假如一个用户出外吃饭时，
正对一个表持有sub-exclusive lock,此时对于表任何锁请求将会阻塞请求队列的头部，所有其它的锁请求将会在它之后排队.