CBC Latch的kcbgtcr: kslbegin excl 揭密

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

逻辑读Cache Buffers Chain Latch（CBC Latch） Miss分析

我们有个库的AWR报告中，有如下的Latch Miss：

cache buffers chains	kcbgtcr: kslbegin excl	0	1,489	1,237
cache buffers chains	kcbchg: kslbegin: bufs not pinned	0	618	657
cache buffers chains	kcbget: pin buffer	0	137	54
cache buffers chains	kcbchg: kslbegin: call CR func	0	73	409
cache buffers chains	kcbrls: kslbegin	0	65	119
………………	………………

         排第一的是kcbgtcr: kslbegin excl，Sleep次数远超同类，它是干什么的。

长久以来，“latch miss”就像Oracle界的UFO话题，代表着神秘、力量和难以理解。Oracle明明准备了这个信息，但又不告诉我们这项信息的准确含义。如同一个MM已经洗完澡、搞的混身香扑扑的，但又紧裹浴袍。

打开浴袍，你就可以“拿走你想要的”，注意，不要只开走她的车，我想kcbgtcr: kslbegin excl不是让我们开走“她”的车。搞错了女孩子的意思，可是非常危险的。

         首先，“秀才认字看半边”，kcbgtcr，这可是大名鼎鼎的逻辑读函数。kcbgtcr: kslbegin excl是否就是逻辑读导致的Latch竞争呢？不一定噢。下面让我们开始我们的Cache Buffers Chains Latch Miss之旅，揭开Latch Miss的神秘面纱。

不过，这个面纱揭的会有点辛苦。

 只见搜索结果中显示：“kcbgtcr 是Oracle数据库最重要的函数之一，其含义为：Kernal Cache Buffer GeT Cosistents Read,也就是数据库的一致性读操作。”

所以，原凶就是：“物理读”。
这真是一个奇怪的结果，逻辑读函数中的Latch竞争，原凶竟然是物理读。
调优的方向，应该是针对物理读最多的一些SQL，这样才有助于减少kcbgtcr: kslbegin excl处的Latch争用。
而这调优逻辑读高的SQL，对于减少kcbgtcr: kslbegin excl处的Latch争用，是没有帮助的。

进一步的，可以将kcbgtcr中的Latch Miss分个类：
一、纯逻辑读相关的
1、kcbgtcr+0x521:                  movq   0xaf5f9e0(%rip),%r8   ---662 kcbgtcr: fast path

2、kcbgtcr+0x27ba:                 movq   0xa718147 (%rip),%r8   ---- kcbgtcr: fast path (cr pin)

二、物理读相关的：
3、kcbgtcr+0x5ba9:                 movq   0xaf5a360(%rip),%r8    ---- 0x663  kcbgtcr: kslbegin excl
       
4、kcbgtcr+0x61eb:                 movq   0xaf59eae(%rip),%r8   --- 695 kcbgtcr_2

5、kcbgtcr+0x6444:                 movq   0xaf599bd(%rip),%r8  --- 642  kcbgtcr: kslbegin shared

6、kcbgtcr+0x976d:                 movq   0xaf56a0c(%rip),%r8   ---6b1 kcbgtcr: L2