latch入门？（最新更新part4：这才是真正的latch）---你所不知道的latch

nanfeng99

好资源
谢谢大家！

Kevin__Zhang

这么老的帖子咋又被翻上来了。

想要进一步了解latch建议去看vage写的一系列本版精华贴。
http://www.itpub.net/thread-1605241-1-1.html
http://www.itpub.net/thread-1609235-1-1.html
http://www.itpub.net/thread-1617245-1-1.html

或者直接去听vaga本人讲课，更有疗效。

Kevin__Zhang

http://www.itpub.net/thread-1478244-1-1.html

lastwinner

比较有研究精神，赞一个

brentt

学习了！

rongshiyuan

看看。。。

liuxuelong007

写的太好了，学习了~！！

deepblueluo

受益！

落日沉鱼

学习，mark！

digdeep126

认认真真的看了两遍，说一下自己的理解。不对的地方请lz指正。

1. latch 的本质是spin lock，也就是通过对总线的控制来保证对latch的读和写是原子的。不用总线控制时，读和写分别是原子操作的，但是合起来不是原子的。
        这里的读就是测试latch是否被别人占用了，写就是表明我已经占据了该latch。有一点 Linux C 基础的人应该好懂一些。
2. latch 有share 和exclusive两种，share latch和 share latch是不互斥的。share latch 和 exlusive latch
        是互斥的，exclusive latch之间也是互斥的。
3. latch 是保护被多个进程共享的内存结构的保护，一般都是共享内存中的各种链表，比如CBC, LRU, LRUW， CHPT-Q, shared pool中的list等。
        保护对链表的增加和删除操作。

4. 对下面结论的解释
1> 当一个操作，走的是唯一索引的话，那么oracle默认目标block是存在于目标链上的，这时，oracle会以shared的模式去获取
cbc latch。如果之后oracle发现弄错了，这个目标块不存在于链上。那么这时，oracle再会尝试以exclsive模式去获得
cbc latch，以将block挂往链上。
2> 但是，如果是全表扫描，oracle会默认的认为目标block肯定是不存在于目标链上的，oracle会直接以exclsive模式去获得cbc latch。

解释：
    1> cbc的作用是什么，我们什么时候用到cbc？这个问题十分重要。我们是在根据地址找内存块时用到cbc，比如server process要寻找块：
        (file#2, block#345)，那么会先对这个地址进行hash，然后找到某个hash list，再找到block header，最后找到block。如果这个block在buffer cache
        中，那么这整个过程需要的是 share cbc latch，如果这个block 不在buffer cache中，那么server process要到磁盘读取这个
        block，然后将他的block header挂到cbc上和lru上，此时必须要申请到 exclusive cbc latch，exclusive lru latch.
    2> 全部扫描，因为没有具体的地址信息，所以无法根据cbc来找block，所以一般会到磁盘读取数据块，然后将读取到的block header挂到
        cbc 和 lru上，挂的时候需要申请 exclusive cbc latch 和 exclusive lru latch.

5. 对下面结论的解释
a.表上无索引，DML操作。
实验结果：大量cbc latch争用，大量buffer busy waits竞争。
b.表上无索引，SELECT操作。
实验结果：大量cbc latch争用， 无任何buffer busy waits竞争。
c.表上有唯一索引，DML操作。
实验结果：无任何cbc latch争用，大量buffer busy waits竞争。
d.表上有唯一索引，SELECT操作。
实验结果：无任何cbc latch争用，无任何buffer busy waits竞争。

解释：
        有了 4 中 的解释，5 的解释应该好理解了：

a. 无索引，DML操作:
        那么server process需要从磁盘读数据块到内存中，并将它们的buffer header插入到CBC和LRU/LRUW上，
        故而必须申请exclusive cbc latch 和 exclusive lru/lruw latch，所以导致了：“大量cbc latch争用，大量buffer busy waits竞争”。
        但是如果dml操作的块都在buffer cache中，那么也不会有“大量cbc latch争用”，但还是会有“大量buffer busy waits竞争”，
        因为脏块要从lru移到lruw，需要申请 exclusive lru latch和exclusive lruw latch.
b. 无索引，select操作，
        解释间4中的2>
c. 有索引，dml:
        那么以 share cbc latch 访问到内存中的block，然后修改，然后从 lru 移到 lruw，所以需要申请 exclusive lru latch和exclusive lruw latch.
        所以：“无任何cbc latch争用，大量buffer busy waits竞争”。
d. 有索引，select:
        那么以 share cbc latch 访问到内存中的block，只有当大量的block 不在内存中时，才需要请大量的exclusive cbc latch 和 exclusive lru latch。
        才会造成：“大量cbc latch争用，大量buffer busy waits竞争”。所以一般情况是：少量的cbc latch争用，少量的buffer busy waits竞争。
其实lz只说了 cbc latch，而没有说“buffer busy waits”
关于buffer busy waits 下面的帖子有解释：
http://www.itpub.net/thread-1372826-1-1.html

总的来说是多个进程对热块的频繁的写导致的。