latch介绍

latch介绍

Latch 属于 System Lock，用于保护 SGA 区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，尤其和一个进程是否需要等待一个 latch、需要等待多长时间有关。

Latch 是 Oracle 提供的轻量级锁资源，是一种能够极快地被获取和释放的锁，能快速、短时间的锁定资源， 防止多个并发进程同时修改访问某个共享资源，它只工作在 SGA 中，通常用于保护描述 buffer cache 中 block 的数据结构。比如 SGA 中，各种数据被反复从磁盘读取到内存，又被重新写回到磁盘上，如果有并发的用户做相同的事情，Oracle 必须使用一种机制，来保证数据在读取的时候，只能由一个会话来完成，这种保护机制就是 Latch。

并发（Concurrency）：指有超过两个以上的用户对同样的数据做修改（可能包括插入，删除和修改）。

并行（Parallel）：指将一件事情分成很多小部分，让每一部分同时执行，最后将执行结果汇总成最终结果。

与每个 latch 相联系的还有一个清除过程，当持有 latch 的进程成为死进程时，该清除过程就会被调用。Latch 还具有相关级别，用于防止死锁，一旦一个进程在某个级别上得到一个 latch，它就不可能再获得等同或低于该级别的 latch。 Latch 不会造成阻塞，只会导致等待。阻塞是一种系统设计上的问题，等待是一种系统资源争用的问题。

有关 SPin 的说明

比如数据缓存中的某个块要被读取，我们会获得这个块的 latch，这个过程叫做 spin，另外一个进程恰好要修改这个块，他也要 spin 这个块，此时他必须等待，当前一个进程释放 latch 后才能 spin 住，然后修改，如果多个进程同时请求的话，他们之间将出现竞争，没有一个入队机制，一旦前面进程释放所定，后面的进程就蜂拥而上，没有先来后到的概念，并且这一切都发生的非常快，因为 Latch 的特点是快而短暂。

SPIN 与休眠（Sleep）：休眠意味着暂时的放弃 CPU，进行上下文切换(Context Switch)，这样 CPU 要保存当前进程运行时的一些状态信息，比如堆栈、信号量等数据结构，然后引入后续进程的状态信息，处理完后再切换回原来的进程状态，这个过程如果频繁的发生在一个高事务，高并发进程的处理系统里面，将是个很昂贵的资源消耗，所以 Oracle 选择了 spin，让进程继续占有 CPU，运行一些空指令，之后继续请求，继续 spin，直到达到_spin_count值，这时会放弃 CPU，进行短暂的休眠，再继续刚才的动作。

进程获取 Latch 的过程

任何时候，只有一个进程可以访问内存中的某一个数据块，如果进程因为别的进程正占用块而无法获得 Latch 时，他会对 CPU 进行一次 spin(旋转)，时间非常的短暂，spin 过后继续获取，不成功仍然 spin，直到 spin 次数到达阀值限制(这个由隐含参数_spin_count 指定)，此时进程会停止 spin，进行短期的休眠，休眠过后会继续刚才的动作，直到获取块上的 Latch为止。

进程休眠的时间也是存在算法的，他会随着 spin 次数而递增，以厘秒为单位，如 1， 1， 2， 2， 4， 4， 8， 8，。。。休眠的阀值限制由隐含参数_max_exponential_slee 控制，默认是 2 秒，如果当前进程已经占用了别的 Latch，则他的休眠时间不会太长(过长会引起别的进程的 Latch 等待)，此时的休眠最大时间有隐含参数_max_sleep_holding_latch 决定，默认是 4厘秒。这种时间限制的休眠又称为短期等待。

另外一种情况是长期等待锁存器(Latch Wait Posting)，此时等待进程请求 Latch 不成功，进入休眠，他会向锁存器等待链表(Latch Wait List)压入一条信号，表示获取 Latch 的请求，当占用进程释放 Latch 时会检查 Latch Wait List，向请求的进程传递一个信号，激活休眠的进程。Latch Wait List 是在 SGA 区维护的一个进程列表，他也需要 Latch 来保证其正常运行，默认情况下 share pool latch 和 library cache latch 是采用这个机制。

如果将隐含参数_latch_wait_posting 设置为 2，则所有 Latch 都采用这种等待方式，使用这种方式能够比较精确的唤醒某个等待的进程，但维护 Latch Wait List 需要系统资源，并且对 Latch Wait List 上 Latch 的竞争也可能出现瓶颈。

如果一个进程请求，旋转，休眠 Latch 用了很长时间，他会通知 PMON 进程查看 Latch的占用进程是否已经意外终止或死亡，如果是，则 PMON 会清除释放占用的 Latch 资源。

总之，Latch 获取的流程：请求-SPIN-休眠-请求-SPIN-休眠 … … 占用。

Latch 和 Lock

从某种意义上说，Latch 是内存中的资源锁，数据库对象(表、索引等)的锁叫 Lock。

Latch 和 Lock 的区别：
（1）、Latch 是对内存数据结构提供互斥访问的一种机制，而 Lock 是以不同的模式来套取共享资源对象，各个模式间存在着兼容或排斥。从这点看出， Latch 的访问，包括查询也是互斥的，任何时候，只能有一个进程能 pin 住内存的某一块。幸好这个过程是相当的短暂，否则系统性能将没有保障，从 9i 开始，允许多个进程同时查询相同的内存块。

（2）、Latch 只作用于内存中，他只能被当前实例访问，而 Lock 作用于数据库对象，在 RAC 体系中实例间允许 Lock 检测与访问。

（3）、Latch 是瞬间的占用、释放，Lock 的释放需要等到事务正确的结束，他占用的时间长短由事务大小决定。

（4）、Latch 是非入队的，而 Lock 是入队的。

（5）、Latch 不存在死锁，而 Lock 中存在。

Latch 争用

如果发现系统中经常由于 Lock 导致用户等待，这时需要考虑系统在逻辑设计上是否有问题，比如多用户对主键的删除或者修改，是否有用户使用 select …for update 这样的语法，外键是否创建索引的因素。这些因素是需要结合系统的业务逻辑性来进行数据库对象设计的。

如果发现系统慢是因为很多的 Latch 争用，就要考虑系统及数据库自身设计上是否存在问题，比如是否使用绑定变量，是否存在热快，数据存储参数设计是否合理等因素。

导致 Latch 争用而等待的原因非常多，内存中很多资源都可能存在争用。 最常见的两类 latch 争用如下：

（1）、共享池中的 Latch 争用。

（2）、数据缓冲池中的 Latch 争用。

1、 共享池中的 Latch 争用

共享池中如果存在大量的 SQL 被反复分析，就会造成很大的 Latch 争用和长时间的等待，最常见的现象就是没有绑定变量。 最常见的集中共享池里的 Latch 是 library cache。

在分析系统性能时，如果看到有 library cache 这样的 Latch 争用，就可以断定是共享池中出现了问题，这种问题基本是由 SQL 语句导致的，比如没有绑定变量或者一些存储过程被反复分析。

2、数据缓冲池 Latch 争用
访问频率非常高的数据块被称为热快（Hot Block），当很多用户一起去访问某几个数据
块时，就会导致一些 Latch 争用， 最常见的 Latch 争用有：

（1）、buffer busy waits

（2）、cache buffer chain

这两个 Latch 的争用分别发生在访问数据块的不同时刻。

Cache buffer chian 产生原因：
当一个会话需要去访问一个内存块时，它首先要去一个像链表一样的结构中去搜索这个数据块是否在内存中，当会话访问这个链表的时候需要获得一个 Latch，如果获取失败，将会产生 Latch cache buffer chain 等待，导致这个等待的

原因是访问相同的数据块的会话太多或者这个列表太长（如果读到内存中的数据太多，需要管理数据块的 hash 列表就会很长，这样会话扫描列表的时间就会增加，持有 cache buffer chain latch 的时间就会变长，其他会话获得这个 Latch 的机会就会降低，等待就会增加）。

Buffer busy waits 产生原因：

当一个会话需要访问一个数据块，而这个数据块正在被另一个用户从磁盘读取到内存中或者这个数据块正在被另一个会话修改时，当前的会话就需要等待，就会产生一个 buffer busy waits 等待。

产生这些 Latch 争用的直接原因是太多的会话去访问相同的数据块导致热快问题，造成热快的原因可能是数据库设置导致或者重复执行的 SQL 频繁访问一些相同的数据块导致。 Latch 是简单的、低层次的序列化技术，用以保护 SGA 中的共享数据结构，比如并发用户列表和 buffer cache 里的 blocks 信息。一个服务器进程或后台进程在开始操作或寻找一个共享数据结构之前必须获得对应的 latch，在完成以后释放 latch。 不必对 latch 本身进行优化，如果 latch 存在竞争，表明 SGA 的一部分正在经历不正常的资源使用。