Latch在数据库层里面业务层面是看不到的，不像锁是可以感知到的，比如一个会话被谁锁定了被谁阻塞住了。
�LOCK
– enqueue：队列，其实就是锁，也就是业务层面的阻塞。enqueue实际上就是队列，要求进程排队使用资源的会话排队
–latch
Latch的目的
�保证资源的串行访问:
– 保护SGA的资源访问
– 保护内存的分配
�保证执行的串行化:
– 保护关键资源的串行执行
– 防止内存结构损坏
Latch是保护数据库本身的内存结构，不是业务层面的保护
Latch V.S. enqueue
Latch不具有队列性，是大家争先恐后的去申请资源，混乱的。enqueue是队列性的，只能等到资源释放了才可以拿到资源，如果没有释放那么只能等着，等释放之后才能拿到锁。
Latch在哪里？---SGA
资源的请求和分配
�共享池
– sql 解析，sql重用....
�数据缓冲池
– 数据访问，数据写入磁盘，数据读入内存...
– 修改数据块
– 数据段扩展
Latch不在PGA里面，PGA不是共享的资源，SGA主要分为两块共享池和数据缓冲池。
Oracle有哪些Latch
Latch的机制
在SGA区里面有一个Latch，这个时候process A获得了一个Latch，获得了Latch就开始干活消耗cpu了，这个时候process B也去尝试获得这个Latch，但是未成功，因为进程A以及持有这个Latch了，这个时候就出现等待了，这个等待就是Latch的获取
Latch的的获取
� wait方式--如果无法获取请求的latch，则：
– spin
• 当一个会话无法获得需要的latch时，会继续使用CPU(CPU 空转），达到一个间隔后，
再次尝试申请latch，直到达到最大的重试次数。
– sleep
• 当一个会话无法获得需要的latch时，会等待一段时间（sleep)，达到一个间隔后，再次
尝试申请latch,如此反复，直到达到最大的重试次数。
� No wait方式--如果无法获取请求的latch，则：
– 不会发生sleep或者spin.
– 转而去获取其它可用的Latch
Latch持有的时间是非常短的，当一个会话去申请Latch的时候恰好有别人在用的时候，当第二次去申请的时候几乎就会成功了，因为获得cpu首先就要去申请cpu，频繁的申请cpu还不如一直持有cpu让cpu空转。
shared pool里的latch争用--绑定变量（share pool里面是对SQL方面进行争用，buffer cache里面的是对数据块的争用）
绑定变量和没有绑定变量对latch的争用。
p1存储过程是没有使用绑定变量的。P2存储过程是做了绑定变量
两个存储过程执行完毕后的对比，run1是没有使用绑定变量的存储过程，run2是使用了绑定变量的存储过程。可以看到run2消耗的资源远小于run1消耗的资源。可以看出绑定变量相对于不绑定变量对share pool消耗大大减小了。
