Latch (转)
http://blog.csdn.net/tianlesoftware/article/details/5263238
2013-05-24 15:33:09 huashanlunjian 阅读数 13更多
分类专栏： 数据库
版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/huashanlunjian/article/details/84435068
一. Latch 说明
1.1 Latch
在之前的一篇文章里的第四部分对Latch 有了说明，参考：
锁 死锁 阻塞 Latch 等待 详解
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5822674.aspx
Latch属于System Lock, 用于保护SGA区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，尤其和一个进程是否需要等待一个latch、需要等待多长时间有关。
Latch是Oracle提供的轻量级锁资源，是一种能够极快地被获取和释放的锁，能快速，短时间的锁定资源，防止多个并发进程同时修改访问某个共享资源，它只工作在SGA中，通常用于保护描述buffer cache中block的数据结构。
比如SGA中，各种数据被反复从磁盘读取到内存，又被重新写回到磁盘上，如果有并发的用户做相同的事情，Oracle必须使用一种机制，来保证数据在读取的时候，只能由一个会话来完成，这种保护机制就是Latch。
并发（concurrency）：是说有超过两个以上的用户对同样的数据做修改（可能包括插入，删除和修改）。
并行（parallel）：是说将一件事情分成很多小部分，让每一部分同时执行，最后将执行结果汇总成最终结果。
与每个latch相联系的还有一个清除过程，当持有latch的进程成为死进程时，该清除过程就会被调用。Latch还具有相关级别，用于防止死锁，一旦一个进程在某个级别上得到一个latch，它就不可能再获得等同或低于该级别的latch。
Latch不会造成阻塞，只会导致等待。 阻塞是一种系统设计上的问题，等待是一种系统资源争用的问题。
1.2 有关SPin 的说明：
比如数据缓存中的某个块要被读取，我们会获得这个块的 latch，这个过程叫做spin，另外一个进程恰好要修改这个块，他也要spin这个块，此时他必须等待，当前一个进程释放latch后才能spin住，然后修改，如果多个进程同时请求的话，他们之间将出现竞争，没有一个入队机制，一旦前面进程释放所定，后面的进程就蜂拥而上，没有先来后到的概念，并且这一切都发生的非常快，因为Latch的特点是快而短暂。
SPIN 与 休眠：
休眠意味着暂时的放弃CPU，进行上下文切换(context switch)，这样CPU要保存当前进程运行时的一些状态信息，比如堆栈，信号量等数据结构，然后引入后续进程的状态信息，处理完后再切换回原来的进程状态，这个过程如果频繁的发生在一个高事务，高并发进程的处理系统里面，将是个很昂贵的资源消耗，所以Oracle选择了spin，让进程继续占有CPU，运行一些空指令，之后继续请求，继续spin，直到达到_spin_count值，这时会放弃CPU，进行短暂的休眠，再继续刚才的动作。
1.3 进程获取Latch的过程:
任何时候，只有一个进程可以访问内存中的某一个数据块，如果进程因为别的进程正占用块而无法获得Latch时，他会对CPU进行一次spin(旋转)，时间非常的短暂，spin过后继续获取，不成功仍然spin，直到 spin次数到达阀值限制(这个由隐含参数_spin_count指定)，此时进程会停止spin,进行短期的休眠，休眠过后会继续刚才的动作，直到获取块上的Latch为止。
进程休眠的时间也是存在算法的，他会随着spin次数而递增，以厘秒为单位，如1，1，2，2，4，4，8，8，。。。休眠的阀值限制由隐含参数_max_exponential_sleep控制，默认是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-休眠 ... ... 占用。
1.4 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中存在。
关于lock 锁可以参考我的blog：
oracle 锁机制
http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4696896.aspx
oracle 锁问题的解决
http://blog.csdn.net/tianlesoftware/archive/2009/10/28/4733630.aspx
二. Latch 争用
如果发现系统中经常由于Lock 导致用户等待，这时需要考虑系统在逻辑设计上是否有问题，比如多用户对主键的删除或者修改，是否有用户使用select… for update这样的语法，外键是否创建索引的因素。 这些因素是需要结合系统的业务逻辑性来进行数据库对象设计的。
如果发现系统慢是因为很多的Latch争用，就要考虑系统及数据库自身设计上是否存在问题，比如是否使用绑定变量，是否存在热快，数据存储参数设计是否合理等因素。
导致Latch争用而等待的原因非常多，内存中很多资源都可能存在争用。 最常见的两类latch争用如下：
（1）共享池中的Latch争用。
（2）数据缓冲池中的latch争用。
Oracle 内存 架构 详解
http://blog.csdn.net/tianlesoftware/archive/2010/05/16/5594080.aspx
2.1 共享池中的Latch争用
共享池中如果存在大量的SQL被反复分析，就会造成很大的Latch争用和长时间的等待，最常见的现象就是没有绑定变量。
最常见的集中共享池里的Latch是 library cache。 可以通过一下SQL 来查询：
SQL> select * from v$latchname where name like ‘library cache%‘;
LATCH# NAME HASH
---------- -------------------------------------------------- ----------
217 library cache 3055961779
218 library cache lock 916468430
219 library cache pin 2802704141
220 library cache pin allocation 4107073322
221 library cache lock allocation 3971284477
222 library cache load lock 2952162927
223 library cache hash chains 1130479025
在分析系统性能时，如果看到有library cache 这样的Latch争用，就可以断定是共享池中出现了问题，这种问题基本是由SQL语句导致的，比如没有绑定变量或者一些存储过程被反复分析。
资源的争用可以通过如下SQL 来查看：
SQL> select event,count(*) from v$session_wait group by event;
EVENT COUNT(*)
---------------------------------------------------------------- ----------
SQL*Ne tmessage from client 4
Streams AQ: waiting for messages in the queue 1
ASM background timer 1
gcs remote message 1
ges remote message 1
jobq slave wait 1
rdbms ipc message 14
smon timer 1
pmon timer 1
Streams AQ: qmn slave idle wait 1
class slave wait 1
SQL*Net message to client 1
Streams AQ: waiting for time management or cleanup tasks 1
Streams AQ: qmn coordinator idle wait 1
DIAG idle wait 1
15 rows selected.
2.2 数据缓冲池Latch争用
访问频率非常高的数据块被称为热快（Hot Block），当很多用户一起去访问某几个数据块时，就会导致一些Latch争用，最常见的latch争用有：
（1） buffer busy waits
（2） cache buffer chain
这两个Latch的争用分别发生在访问数据块的不同时刻。
关于等待事件的说明，具体参考：
Oracle 常见的33个等待事件
http://blog.csdn.net/tianlesoftware/archive/2010/08/12/5807800.aspx
Cache buffer chian产生原因：
当一个会话需要去访问一个内存块时，它首先要去一个像链表一样的结构中去搜索这个数据块是否在内存中，当会话访问这个链表的时候需要获得一个Latch，如果获取失败，将会产生Latch cache buffer chain 等待，导致这个等待的原因是访问相同的数据块的会话太多或者这个列表太长（如果读到内存中的数据太多，需要管理数据块的hash列表就会很长，这样会话扫描列表的时间就会增加，持有chache buffer chain latch的时间就会变长，其他会话获得这个Latch的机会就会降低，等待就会增加）。
Buffer busy waits 产生原因：
当一个会话需要访问一个数据块，而这个数据块正在被另一个用户从磁盘读取到内存中或者这个数据块正在被另一个会话修改时，当前的会话就需要等待，就会产生一个buffer busy waits等待。
产生这些Latch争用的直接原因是太多的会话去访问相同的数据块导致热快问题，造成热快的原因可能是数据库设置导致或者重复执行的SQL 频繁访问一些相同的数据块导致。
Latch是简单的、低层次的序列化技术，用以保护SGA中的共享数据结构，比如并发用户列表和buffer cache里的blocks信息。一个服务器进程或后台进程在开始操作或寻找一个共享数据结构之前必须获得对应的latch，在完成以后释放latch。不必对latch本身进行优化，如果latch存在竞争，表明SGA的一部分正在经历不正常的资源使用。
有关这部分的更多内容，参考：
锁 死锁 阻塞 Latch 等待 详解
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5822674.aspx
三. 检查Latch 的相关SQL
3.1 查看造成LATCH BUFFER CACHE CHAINS等待事件的热快
SELECT DISTINCT a.owner, a.segment_name
FROM dba_extents a,
(SELECT dbarfil, dbablk
FROM x$bh
WHERE hladdr IN (SELECT addr
FROM ( SELECT addr
FROM v$latch_children
ORDER BY sleeps DESC)
WHERE ROWNUM < 20)) b
WHERE a.RELATIVE_FNO = b.dbarfil
AND a.BLOCK_ID <= b.dbablk
AND a.block_id + a.blocks > b.dbablk;
3.2 查询当前数据库最繁忙的Buffer，TCH(Touch)表示访问次数越高，热点快竞争问题就存在
SELECT *
FROM ( SELECT addr,
ts#,
file#,
dbarfil,
dbablk,
tch
FROM x$bh
ORDER BY tch DESC)
WHERE ROWNUM < 11;
3.3 查询当前数据库最繁忙的Buffer，结合dba_extents查询得到这些热点Buffer来自哪些对象
SELECT e.owner, e.segment_name, e.segment_type
FROM dba_extents e,
(SELECT *
FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch
FROM x$bh
ORDER BY tch DESC)
WHERE ROWNUM < 11) b
WHERE e.relative_fno = b.dbarfil
AND e.block_id <= b.dbablk
AND e.block_id + e.blocks > b.dbablk;
3.4 如果在Top 5中发现latch free热点块事件时，可以从V$latch_children中查询具体的子Latch信息
SELECT *
FROM (SELECT addr, child#, gets, misses, sleeps, immediate_gets igets,
immediate_misses imiss, spin_gets sgets
FROM v$latch_children
WHERE NAME = ‘cache buffers chains‘
ORDER BY sleeps DESC)
WHERE ROWNUM < 11;
3.5 获取当前持有最热点数据块的Latch和buffer信息
SELECT b.addr, a.ts#, a.dbarfil, a.dbablk, a.tch, b.gets, b.misses, b.sleeps
FROM (SELECT *
FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch, hladdr
FROM x$bh
ORDER BY tch DESC)
WHERE ROWNUM < 11) a,
(SELECT addr, gets, misses, sleeps
FROM v$latch_children
WHERE NAME = ‘cache buffers chains‘) b
WHERE a.hladdr = b.addr;
3.6 利用前面的SQL可以找到这些热点Buffer的对象信息
SELECT distinct e.owner, e.segment_name, e.segment_type
FROM dba_extents e,
(SELECT *
FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch
FROM x$bh
ORDER BY tch DESC)
WHERE ROWNUM < 11) b
WHERE e.relative_fno = b.dbarfil
AND e.block_id <= b.dbablk
AND e.block_id + e.blocks > b.dbablk;
3.7 结合SQL视图可以找到操作这些对象的相关SQL，然后通过优化SQL减少数据的访问，或者优化某些容易引起争用的操作（如connect by等操作）来减少热点块竞争
break on hash_value skip 1
SELECT /*+ rule */ hash_value,sql_text
FROM v$sqltext
WHERE (hash_value, address) IN (
SELECT a.hash_value, a.address
FROM v$sqltext a,
(SELECT DISTINCT a.owner, a.segment_name, a.segment_type
FROM dba_extents a,
(SELECT dbarfil, dbablk
FROM (SELECT dbarfil, dbablk
FROM x$bh
ORDER BY tch DESC)
WHERE ROWNUM < 11) b
WHERE a.relative_fno = b.dbarfil
AND a.block_id <= b.dbablk
AND a.block_id + a.blocks > b.dbablk) b
WHERE a.sql_text LIKE ‘%‘ || b.segment_name || ‘%‘
AND b.segment_type = ‘TABLE‘)
ORDER BY hash_value, address, piece;
文章来自：http://blog.csdn.net/tianlesoftware/article/details/5263238
原文地址：https://www.cnblogs.com/jinanxiaolaohu/p/11840673.html