揭密Oracle之七种武器之三：破译古老的谜题---共享CBC Latch的秘密
揭密Oracle之七种武器之三：破译古老的谜题---共享CBC Latch的秘密
（前两章地址
揭密Oracle之 七种武器 章 搭建测试环境（目前已到第三章）
http://www.itpub.net/thread-1605241-1-1.html
揭密Oracle之七种武器二：DTrace语法：跟踪物理IO
http://www.itpub.net/thread-1609235-1-1.html
）
从9iR2开始，Cache Buffers Chain（以下简称CBC）Latch就变成共享Latch了。从那时开始，我想当然的认为，如果我只有读操作，互相之间就不会阻
塞了。于是马上测试：
declare
myid number;
begin
for i in 1..10000000 loop
select id1 into myid from a2_70m where rowid='AAACYJAAEAAAAAUAAA';
end loop;
end;
/
这段过程很简单，就是反复的逻辑读某一行。将这段过程在两个会话同时执行，我天真的认为，不会再看到CBC Latch等待。但是，查看等待事件的结果
，令我深深的迷惑。为什么还是有等待呢？无论CBC 链还是数据块，我都没有修改，只是反复读取，为什么共享Latch不共享呢？从此，这个迷团一直困绕着我。
当然，还有其他一些谜团，比如索引和非索引在读扫描时的区别。普通的区别，是它们两个逻辑读不一样，索引比非少一个逻辑读
。但其实，它们两个的区别非常大。具体的区别在哪里？这些区别对于我们的选择，会有什么影响？
这些谜团很长一段时间内没有答案。
五、六年转眼即过，2011年初，因公司技术转型，我被迫从头学起GreenPlum。翻开几百页的英文文档，我不禁倦意袭来。再看会Oracle的资料，又不禁
精神百倍。于是，我退意蒙生。但是，这段经历，让我有一个意外的收获。阿里的GreenPlum，都是跑在Solaris下。接手GreenPlum运维，必先学会Solaris。在
学习Solaris时，看到有一本书用两页纸介绍了一个工具：DTrace语言，说是可以跟踪Solaris中的任何操作。当时我对Oracle的研究，也陷入了困境。能用的跟
踪事件都用了，很多原理还是无法搞清楚，只能跟着别人，人云亦云一下，自我感觉对Oracle了解甚为深入，已经没什么可以再学的了。但分析一些工作中奇怪
的问题，就总感觉似是，而非。
这种感觉让我想起来多年前，年青的时候我酷爱神秘文化。什么东西都信，曾在二月底初春时节跳入溥冰覆盖的河水中受洗，随身携带一本荒漠甘泉。
在被女神无情抛弃后，独自站在空旷的教堂祈祷：“仁慈的圣父啊，我知道这是您对我的庇护和煅炼，虽然您的孩子此刻心如刀绞，但我仍然感谢您、爱您。哈
利路亚，阿门。”不久之后，下一位女神出现，却是信佛的。于是我又到家乡的大相国寺，皈依佛祖，每逢初一、十五，烧香诵经：“南无西方琉璃药师佛
，南无……”。
在诸多杂学之中，我精通的却还是周易。刚刚参加工作哪会，我为我们科室6个人占卦，算他们哪一年结婚、哪一年有小孩，6个人，只有一个算错了
。83%的准确率，很高了。但是，为什么有一次算错了呢？为什么其他的可以算对呢？这些问题我都答不上来，我对周易的理解，始终似是，而非。
易经这东西，真正的神人传下来的，几千年中，看懂的没几个。但是Oracle呢，我也无法真正的看“懂”它吗。对易经的理解似是而非，这我服气，但
对Oracle，我不想停留在似是而非的境界。
当看到这个DTrace后，我眼前顿时一亮，如果用DTrace跟踪Oracle，又会有怎样的效果呢？是否可以打破“似是而非”的僵局呢？于是我马上搜集资料
开始学习，这一下，没想到豁然为我打开一扇大门。于是我再也顾不得什么GreenPlum、什么KPI了。:)
好了，言归正传，这一节，从一个重要的提供器开始，PID进程提供器。Solaris在进程调用、退出每个函数时，都设置了Prob，进程提供器的作用就是
打开这些Prob。
我们可以写如下的脚本，打开PID提供器所有调用函数时的探针：
pid1234:::entry
{
动作;
}
这个脚本的作用是打开1234进程所有函数调用处的探针。简单点说，1234进程每调一次函数，都会被触发。这个脚本还可以进一步改成这样：
pid$1:::entry
{
动作;
}
用$1代替了1234。$1，这种写法是来自于Shell脚本编程，个参数。当然，我们也可以pid$2。
接下来，我们可以定义什么动作呢？当然还是观察了.
在我上传的《Solaris 动态跟踪指南》书中，P68页，列出了全部的内置变量，这次，我们使用这几个内置变量：probeprov, probemod, probefunc,
probename,arg0和arg1……
probeprov：提供器名
probemod : 模块名
probefunc：函数名，这是我们要查看的重点。
probename：探针名，只有两个。entry，return，一个进入、一个是退出。
arg0,arg1,…… ：调用函数时，传递给函数的参数。
这些内置变量，无需定义，可以直接使用。内置变量中保存了很多重要的值，在上篇文章已经有用到过。
好，我们的终脚本程序，是这个样子：
这个探针的使用很简单，我们总的脚本如下：
#!/usr/sbin/dtrace -s -n
dtrace:::BEGIN
{
i=1;
}
pid$1:::entry
{
printf("i=%d PID::entry:==%s:%s:%s:%s %x %x %x %x %x %x",i, probeprov, probemod, probefunc, probename,arg0,arg1,arg2,arg3,arg4,arg5);
i=i+1;
}
参数这块，我们也不知道每个函数都有几个参数，好在多输出参数DTrace并不会报错，所以，我们就多显示几个参数，我显示了前6个：
arg0,arg1,arg2,arg3,arg4,arg5。都以%x，16进程格式显示。
将此脚本保存为all_func.d，授于执行权限，开始执行。
对了，别忘了，本章的目的，是观察CBC Latch。更进一步的，观察逻辑读的CBC Latch。
打开一个会话，查询出它对应的进程号：
SQL> select c.sid,spid,pid,a.SERIAL# from (select sid from v$mystat where rownum<=1) c,v$session a,v$process b where c.sid=a.sid and
a.paddr=b.addr;
SID SPID PID SERIAL#
---------- ------------ ---------- ----------
863 970 22 1
我的进程号是970。另外，在开始观察前，执行几次如下语句，让读是逻辑读：
select * from a2_70m where rowid='AAACYJAAEAAAAAUAAA';
如下运行脚本，观察970号进程：
# ./all_func.d 970 > logic_read1.log
dtrace: script './all_func.d' matched 124179 probes
根据显示结果，共有124179个探针被打开。十几万个探针，说明Oracle内部，有十几万个函数。C语言中，程序代码的复用，全靠函数了。C又被称为函
数语言吗。不过，Oracle内部竞然有十几万个函数，还是出乎我的意料。不过，函数分的越细，对我们调试、跟踪越好。在没有源代码的情况下，我们只能跟踪
到函数级别了。
跟踪结果会很多，为了便于观察，我将结果重定向到logic_read1.log文件中。
另外，由于会打开太多探针，有可能会超出DTrace的限制，报出错误，可以修改/kernel/drv/fasttrap.conf中fastrap-max-probes设置，在我的测试环
境中，我设置为fastrap-max-probes=1000000。
另外，如果在970进程执行期间，all_func.d脚本报内存不足，可以在脚本开头加上去内存大小或刷新频率的设置：
#!/usr/sbin/dtrace -s -n -x switchrate=10hz -b 16m
-x switchrate=10hz，设置刷新频率。DTrace会结果发送到输出终端，这个值可以理解为发送频率。在数据没有发送到输出终端前，DTrace会先保存到
自己的缓存中。因此，增加刷新频率，可以减少内存使用。
-b 16m ， 修改缓存大小。
好了，来看结果吧，在970进程对应的会话中，再执行一次：
select * from a2_70m where rowid='AAACYJAAEAAAAAUAAA';
回到执行DTrace命令的窗口，按Ctrl+C。然后查看结果，先看一下有多少行输出吧：
# cat logic_read1.log|wc -l
1211
1211行，这是运行一次软软解析，再加上对一个块逻辑读取出一行，Oracle所要调用的函数次数。这也是我们细粒度的跟踪级别了。比10046等任何一
个Event，都要细致的多。除非你去看源码，否则，不可能比这个更细、更深入了。
下面，让我们来看看结果都是什么吧：
# cat logic_read1.log|more
CPU ID FUNCTION:NAME
3 172611 memcpy:entry i=1 PID::entry:==pid970:libc.so.1:memcpy:entry 8047708 c0f2c28 1 c028934 c02a6dc 6
3 52316 kslwte_resmgr:entry i=2 PID::entry:==pid970:oracle:kslwte_resmgr:entry 100 62657100 1 0 8047708 c028894
3 174943 gethrtime:entry i=3 PID::entry:==pid970:libc.so.1:gethrtime:entry c07ad01 80461e4 80461e4 8dd9467 100 62657100
3 52313 kslwte_tm:entry i=4 PID::entry:==pid970:oracle:kslwte_tm:entry 100 62657100 1 0 cfacb398 1
3 111268 skgslnoop:entry i=5 PID::entry:==pid970:oracle:skgslnoop:entry c028934 c02a6dc 0 8046130 c0e7078 b0fc070
3 86139 kews_idle_wait:entry i=6 PID::entry:==pid970:oracle:kews_idle_wait:entry 8c9775bd 0 c028934 c02a6dc 0 8046130
3 174943 gethrtime:entry i=7 PID::entry:==pid970:libc.so.1:gethrtime:entry 8f1e27a0 8f18c820 8c9775bd a9c0001 c07ad9c 80460f0
3 86061 kewe_trace_level:entry i=8 PID::entry:==pid970:oracle:kewe_trace_level:entry 8f18c820 c028934 c02a6dc 0 8046130 c0e7078
3 52312 ksl_which_bucket:entry i=9 PID::entry:==pid970:oracle:ksl_which_bucket:entry 2325dd c028934 c02a6dc 0 8046130 c0e7078
3 53333 kskthewt:entry i=10 PID::entry:==pid970:oracle:kskthewt:entry c07ad01 80461e4 80461e4 8dd9467 100 62657100
3 172611 memcpy:entry i=11 PID::entry:==pid970:libc.so.1:memcpy:entry 8047714 c0f2c29 2 101 c028890 c0e7120
3 104873 kpuhhmrk:entry i=12 PID::entry:==pid970:oracle:kpuhhmrk:entry c028850 101 c028890 c0e7120 804773c 0
…………………………
…………………………
…………………………
以行为例，pid970:libc.so.1:memcpy:entry，pid970是提供器名，libc.so.1是模块名，memcpy是函数名，entry是探针名。
我摘出前十几行，DTrace是能以很细的粒度跟踪Oracle，细致程度远超10046，但问题来了，我们如何解读跟踪结果。这是一个很重要的问题。
简单点说，这些函数都是干吗的。不要指望谁能告诉你，现在，进行这种探索的，还非常非常少。这方面的资料，就不要奢望了。来吧，Maoyeye教导我
们，自己动手，丰衣足食。
我们不需要、也可能能搞清楚这每一行函数调用都是干吗的。Oracle的代码量哪么庞大，估计Oracle的开发人员，也不可能搞清楚这每一行全部的意义
。我们只需要搞清楚，我们自己关心的就行了。比如，我一开始所说的，Oracle在什么时候加什么的Mutex、Latch、Pin、Lock，什么时候释放，会以怎样的形式
阻塞，等等。
我们今天，先以CBC Latch为例，说一下研究它的思路。其他的也都类似。我想做的，不是告诉你一个结果，而是这结果是怎么来的，让我们大家都可以
都可以用这种方式去研究。
每个Latch，都有一个地址，哪么，Oracle在调函数去获得、获放Latch时，应该会将此地址做为参数。好，马上，查找Latch的地址：
1、找出测试语句中ROWID在哪个文件哪个块：
SQL> select dbms_rowid.ROWID_RELATIVE_FNO('AAACYJAAEAAAAAUAAA'),dbms_rowid.rowid_block_number('AAACYJAAEAAAAAUAAA') from dual;
DBMS_ROWID.ROWID_RELATIVE_FNO('AAACYJAAEAAAAAUAAA') DBMS_ROWID.ROWID_BLOCK_NUMBER('AAACYJAAEAAAAAUAAA')
--------------------------------------------------- ---------------------------------------------------
4 20
测试语句要查找的行在4号文件、20号块
2、在x$BH中，找到此块在哪个Latch的保护下：
SQL> select file#,dbablk,tch,lower(HLADDR) from x$bh where file#=4 and dbablk=20;
FILE# DBABLK TCH LOWER(HL
---------- ---------- ---------- --------
4 20 3 8ea1d750
4号文件20号块，是受地址为8ea1d750的Latch保护。
3、在跟踪结果文件中查找相关的：
# cat logic_read1.log|grep 8ea1d750
3 111575 sskgslcas:entry i=517 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 fdc3f1e4 fdc3f18c fdc3f1e4
3 111578 sskgsldecr:entry i=526 PID::entry:==pid970:oracle:sskgsldecr:entry 8ea1d750 20000016 fdc3f1e4 fdc3f18c fdc3f1e4 804544c
3 111575 sskgslcas:entry i=552 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 1 fdc3f17c 81e1c064
3 57740 kcbzar:entry i=557 PID::entry:==pid970:oracle:kcbzar:entry 8ef9a5b4 8ea1d750 108000 8045368 1 fdc3f17c
3 101760 slmxnoop:entry i=558 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 101760 slmxnoop:entry i=559 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 101760 slmxnoop:entry i=560 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 101760 slmxnoop:entry i=561 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 101760 slmxnoop:entry i=562 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 101760 slmxnoop:entry i=564 PID::entry:==pid970:oracle:slmxnoop:entry 81ff1de4 fdc3f1ec 8ea1d750 8045338 a9bdd25 c030d18
3 111578 sskgsldecr:entry i=566 PID::entry:==pid970:oracle:sskgsldecr:entry 8ea1d750 20000016 1 fdc3f17c 81e1c064 8045510
3 52568 kssrmf:entry i=568 PID::entry:==pid970:oracle:kssrmf:entry 8ef9a590 8e94811c 81ff1de4 20000016 8ea1d750 8ef9a5b4
和这个地址相关的有这十几行。在这里，有一点编程习惯再说一下，要申请某一个地址处的Latch，这个Latch的地址，是这个函数的重要的参数，因
此，Oracle会把它排在位，也就是说，以上这十几行中，个参数不是8ea1d750的，基本可以排队掉了。
所以，我们只剩这些行需要关注：
# cat logic_read1.log|grep "entry 8ea1d750"
3 111575 sskgslcas:entry i=517 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 fdc3f1e4 fdc3f18c fdc3f1e4
3 111578 sskgsldecr:entry i=526 PID::entry:==pid970:oracle:sskgsldecr:entry 8ea1d750 20000016 fdc3f1e4 fdc3f18c fdc3f1e4 804544c
3 111575 sskgslcas:entry i=552 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 1 fdc3f17c 81e1c064
3 111578 sskgsldecr:entry i=566 PID::entry:==pid970:oracle:sskgsldecr:entry 8ea1d750 20000016 1 fdc3f17c 81e1c064 8045510
这四行，两个函数调用，sskgslcas、sskgsldecr，个参数都是Latch的地址：8ea1d750。我相信这不是巧合，它们肯定是申请、释放Latch的函数。
i=517这行，Oracle调用sskgslcas持有Latch，在i=526这行，调用sskgsldecr释放，接下来在i=552又一次调用sskgslcas持有Latch，在i=566处调用
sskgsldecr释放。一次逻辑读对应两次Latch调用。
结果是这样吗，让我们继续验证，Oracle的Oradebug可以调用某个Oracle自身的函数，就有它来验证吧：
SQL> oradebug setmypid
Statement processed.
SQL> oradebug call sskgslcas 0x8ea1d750 0 0x20000016 0xfdc3f1e4
Function returned 1
SQL>
sskgslcas参数的取值，就是我们上面的跟踪结果。我只用了4个参数，其实应该只有3个参数。但是，用Oradebug时，多传了参数也无所谓。
Function returned 1，这一行说明我们的调用是成功的。
回到970进程对应的会话，再次执行如下语句：
SQL> select * from a2_70m where rowid='AAACYJAAEAAAAAUAAA';
被Hang住了，在另一个会话中查看等待事件（970号进程对应的会话ID是863）：
SQL> select sid,event,p1raw,p2 from v$session where sid=863;
SID EVENT P1RAW P2
---------- ---------------------------------------------------------------- -------- ----------
863 latch: cache buffers chains 8EA1D750 122
863果然在等待CBC Latch，而且根据P1RAW列的值，所等的Latch就是8EA1D750。接着，sskgsldecr是释放Latch，继续验证此点，在刚才Oradebug的会话
中继续执行：
SQL> oradebug call sskgsldecr 0x8ea1d750 0x20000016
Function returned 20000016
同样，sskgsldecr 0x8ea1d750 0x20000016，这个函数的参数来自于我们的跟踪文件。我们这样手动调用结束，刚才被Hang的会话，已经可以顺利执行
下去了。说明Latch已经被释放。
看，我们很轻松就已经找到了Oracle申请、释放CBC Latch的函数。一切都是如此简单。
到这里，可能有人会有不同意见了。如果你看过其他一些牛人的书，包括Oracle的DSI405，都说到Latch的调用、释放，是用kslgetl（独占）、
kslgetsl（共享）和kslfre，怎么我又说申请、释放Latch是另外的函数呢。
这很容易理解，DSI405是讲9i的。其他牛人说的也没错，kslgetl（独占）、kslgetsl（共享）和kslfre的确也是Latch相关的函数。物理读一个块时，
Oracle也会用这三个函数来加、释放CBC Latch，但逻辑读不是。
这很容易理解，逻辑读是繁忙的操作，Oracle专门为它开个小灶、做做优化不是很正常吗。而且，提前说一下，Mutex也是用sskgslcas申请的（释放
不是用sskgsldecr），关于Mutex内幕，我们到后几章再详细说，顺便说一句，要想揭开Mutex内幕，也只有D&G（DTrace+GDB）了。
我们还要再接着研究。CBC Latch的地址是8ea1d750，在这个地址处，Oracle都放了什么呢。有两种方式可以观察这个，用Oradebug，或者，改写我们的
DTrace脚本。我用后一种方式吧，这种方式早晚要熟练掌握的，而且并不是每个要观察的值，都可以用Oradebug。
使用DTrace，如果参数是地址的话，将地址的址读出来，这种方法在上一章中已经有描述了，如下修改脚本程序：
#!/usr/sbin/dtrace -s -n
char *memnr;
int latchaddr;
dtrace:::BEGIN
{
i=1;
latchaddr=0;
}
pid$1::sskgslcas:entry
{
memnr=copyin(arg0,12);
latchaddr=arg0;
printf("[%2x%2x%2x%2x|%2x%2x%2x%2x|%2x%2x%2x%2x]",memnr[3],memnr[2],memnr[1],memnr[0],memnr[7],memnr[6],memnr[5],memnr[4],memnr
[11],memnr[10],memnr[9],memnr[8]);
printf("i=%d PID::entry:==%s:%s:%s:%s %x %x %x %x %x %x",i, probeprov, probemod, probefunc, probename,arg0,arg1,arg2,arg3,arg4,arg5);
i=i+1;
}
pid$1::sskgslcas:return
{
memnr=copyin(latchaddr,12);
printf("[%2x%2x%2x%2x|%2x%2x%2x%2x|%2x%2x%2x%2x]",memnr[3],memnr[2],memnr[1],memnr[0],memnr[7],memnr[6],memnr[5],memnr[4],memnr
[11],memnr[10],memnr[9],memnr[8]);
printf("i=%d PID::entry:==%s:%s:%s:%s %x %x %x",i, probeprov, probemod, probefunc, probename,latchaddr,arg0,arg1);
i=i+1;
}
在这个脚本中，我只观察CBC的申请和释放。copyin函数的使用，上一章有，不再重述。需要注意的时，我在pid$1::sskgslcas:entry中，执行了这样一
行：latchaddr=arg0；目的是将Latch的地址保存到全局变量latchaddr中。然后，在sskgslcas申请Latch后，再观察一下此地址中的值。
看一下观察结果吧：
# cat logic_read2.log|grep "8ea1d750"
0 111575 sskgslcas:entry [ 0 0 0 0| 0 0 291| 0 0 07a]i=3 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 fdc1a2dc fdc1a284 fdc1a2dc
0 175725 sskgslcas:return [20 0 016| 0 0 291| 0 0 07a]i=4 PID::entry:==pid970:oracle:sskgslcas:return 8ea1d750 16 1
0 111575 sskgslcas:entry [ 0 0 0 0| 0 0 292| 0 0 07a]i=5 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 20000016 1
fdc1a274 81e1c064
0 175725 sskgslcas:return [20 0 016| 0 0 292| 0 0 07a]i=6 PID::entry:==pid970:oracle:sskgslcas:return 8ea1d750 16 1
我显示了latch地址处的12个字节，我将结果整理一下：
进入sskgslcas函数时：[ 0 0 0 0| 0 0 291| 0 0 07a]
从sskgslcas返回时 ：[20 0 016| 0 0 291| 0 0 07a]
进入sskgslcas函数时：[ 0 0 0 0| 0 0 292| 0 0 07a]
从sskgslcas返回时 ：[20 0 016| 0 0 292| 0 0 07a]
我一共显示了12个字节。后4个节字，7A，10进制是122。这个是Latch编号。中间4个字节，291、292，明显是我访问的次数。这些可以从v
$latch_children视图中得到。后4个字节是LATCH#列，中间4个字节，就是GETS列了。
前面4个字节，20000016，正好是sskgslcas的第三个参数。我觉得这个应该是模式。
看来，sskgslcas的作用，应该就是将第三个参数的值“20000016”交换到Latch 地址所指向的内存中。然后访问次数加1。
接下来，该如何确定20000016是否是模式呢？这个，从这里就看不出来了，我们要找个索引试试。
在我的测试表a2_70m，ID1列上有个索引，索引名是A2_70M_ID1。我使用如下测试语句：
SQL> select * from a2_70m where id1=1;
ID1 ID2 CC1
---------- ---------- ------------------------------
1 10 A-----------------------------
以上语句，多执行个几次，在另一个会话中，查看索引的块和Latch地址：
SQL> set pagesize 50000
SQL> set linesize 10000
SQL> select file#,dbablk,tch,ba,HLADDR from x$bh a,dba_objects b where a.obj=b.data_object_id and object_name='A2_70M_ID1' order by
FILE#,DBABLK;
FILE# DBABLK TCH BA HLADDR
---------- ---------- ---------- -------- --------
5 23449 0 8189E000 8E98DAD4
5 23450 0 81A74000 8EAF0390
5 23451 0 8189C000 8EA150C8
5 23452 3 81A78000 8EB77E00
5 23453 3 81A76000 8EA9CB38
5 23454 0 81A72000 8E9C13F4
5 23455 0 8189A000 8EB2412C
5 23456 0 81A70000 8EA48E64
6 5695 3 818A0000 8EACBC98
多执行几次测试语句，找出TCH值不断在增加的，这些块就是索引扫描时相关的块了。我这里是5号文件23452、23453块，和6号文件5695块。索引的root
块，都是段头的下一个块，我们可以如下确认一下：
SQL> select segment_name,header_file,header_block from dba_segments where segment_name=upper('A2_70M_ID1');
SEGMENT_NAME HEADER_FILE HEADER_BLOCK
------------------------------ ----------- ------------
A2_70M_ID1 5 23451
段头是23451块，哪么23452就是root块了。提一个注意事项，索引扫描在10.2.0.2后是不用读段头的，真接Root、枝、叶。但在10.2.0.1，有时还是需
要读段头的。
好，用我们刚才的脚本，开始观察吧。
先执行脚本：
# ./all_func.d 970 > logic_read3.log
dtrace: script './all_func.d' matched 3 probes
再执行测试SQL，显示logic_read3.log内容，观察结果，先看根块吧：
# cat logic_read3.log|grep 8eb77e00
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 721| 0 0 07a]i=3 PID::entry:==pid970:oracle:sskgslcas:entry 8eb77e00 0 1 fdc1a3bc fdc1a3b4 fdc1a278
1 175725 sskgslcas:return [ 0 0 0 1| 0 0 721| 0 0 07a]i=4 PID::entry:==pid970:oracle:sskgslcas:return 8eb77e00 16 1
根块Latch的地址是8eb77e00，先只看一下根块。注意第三个参数，不是20000016，而是1。我们自己调一下试试：
SQL> oradebug call sskgslcas 0x8eb77e00 0 1
Function returned 1
（释放是：
SQL> oradebug call sskgsldecr 0x8eb77e00 1
Function returned 1
）
再到另一个会话执行测试SQL，不会被阻塞。看来这才是共享模式啊。再往下看跟踪文件，8eacbc98是root块后接着申请的一个Latch，它对应6号文件
5695号块。看来它是枝块了。
# cat logic_read3.log|grep 8eacbc98
2 111575 sskgslcas:entry [ 0 0 0 0| 0 0 784| 0 0 07a]i=5 PID::entry:==pid970:oracle:sskgslcas:entry 8eacbc98 0 1 fdc3f2c4 fdc3f2bc fdc3f180
2 175725 sskgslcas:return [ 0 0 0 1| 0 0 784| 0 0 07a]i=6 PID::entry:==pid970:oracle:sskgslcas:return 8eacbc98 16 1
枝块获得CBC Latch，也是共享的。
那么5号文件23453块，它应该是叶块了，查看它的获取Latch情况：
# cat logic_read3.log|grep 8ea9cb38
2 111575 sskgslcas:entry [ 0 0 0 0| 0 0 783| 0 0 07a]i=7 PID::entry:==pid970:oracle:sskgslcas:entry 8ea9cb38 0 1 fdc3f2c4 fdc3f2bc fdc3f180
2 175725 sskgslcas:return [ 0 0 0 1| 0 0 783| 0 0 07a]i=8 PID::entry:==pid970:oracle:sskgslcas:return 8ea9cb38 16 1
2 111575 sskgslcas:entry [ 0 0 0 0| 0 0 784| 0 0 07a]i=13 PID::entry:==pid970:oracle:sskgslcas:entry 8ea9cb38 0 20000016 ffffffff fdc3f2c4 fdc3f17c
2 175725 sskgslcas:return [20 0 016| 0 0 784| 0 0 07a]i=14 PID::entry:==pid970:oracle:sskgslcas:return 8ea9cb38 16 1
2 111575 sskgslcas:entry [ 0 0 0 0| 0 0 785| 0 0 07a]i=15 PID::entry:==pid970:oracle:sskgslcas:entry 8ea9cb38 0 20000016 c030e14 fdc3f180 fdc3f2bc
2 175725 sskgslcas:return [20 0 016| 0 0 785| 0 0 07a]i=16 PID::entry:==pid970:oracle:sskgslcas:return 8ea9cb38 16 1
2 111575 sskgslcas:entry [ 0 0 0 0| 0 0 786| 0 0 07a]i=17 PID::entry:==pid970:oracle:sskgslcas:entry 8ea9cb38 0 20000016 0 fdc3f2c4 fdc3f2b8
2 175725 sskgslcas:return [20 0 016| 0 0 786| 0 0 07a]i=18 PID::entry:==pid970:oracle:sskgslcas:return 8ea9cb38 16 1
它一共获取了4次，次是共享的，后面三次，是独占的。后还可以再看一下表块，表块要获得两次，都是独占的。这样看来，索引叶块的CBC
Latch的争用，要比表块多啊。建议索引的PCTFREE可以调的比表高些，既能减少中间块分裂的总次数。块中行更少，又能分散争用。
但这样做会使索引树层数升高，增加索引访问时的逻辑读。对于解决索引块上的CBC Latch争用，这样做还是非常值得的。因为同样是逻辑读，消耗的资
源可是不以同日而语的。索引枝块只需要一次CBC Latch，而且是共享的，并且，不需要把数据拷贝到PGA中，只在Buffer Cache中比较一下Key值，取出下一层块
的位置。这种逻辑读，不会造成争用，因为从头到尾，所有资源都是共享的，所耗资源比表块逻辑读也少的多。而且大的PCTFree，还可以减少索引块分裂次数。
因此，使用这种方式，减少索引叶块的CBC Latch争用，是可行的。
好，经过上面的测试，本章开头提到个问题，已经有了答案。为什么共享的CBC Latch会有争用，答案是因为Oracle以独占的方式持有了它。
在文章开头，我还提到过一个问题，就是索引和非索引读扫描时的区别，刚才我的测试索引，不是非的，我把它重建为索引试试，我
们可以比较下，区别还是非常大的：
SQL> drop index a2_70m_id1;
Index dropped.
SQL> CREATE unique INDEX a2_70m_id1 on a2_70m(id1);
Index created.
我们的测试语句和刚才相同，只不过这次它的访问路径是索引扫描。
索引的测试结果，和非有很大不同：
# cat logic_read3.log
CPU ID FUNCTION:NAME
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 01d| 0 0 0 0]i=1 PID::entry:==pid970:oracle:sskgslcas:entry 87d88194 0 35f0001 8886a9c8 87d88194 888f7c48
1 175725 sskgslcas:return [ 35f 0 1| 0 0 01d| 0 0 0 0]i=2 PID::entry:==pid970:oracle:sskgslcas:return 87d88194 16 1
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 c67| 0 0 07a]i=3 PID::entry:==pid970:oracle:sskgslcas:entry 8eb77e00 0 1 804520c 8045204 fda522f8
1 175725 sskgslcas:return [ 0 0 0 1| 0 0 c67| 0 0 07a]i=4 PID::entry:==pid970:oracle:sskgslcas:return 8eb77e00 16 1
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 bc3| 0 0 07a]i=5 PID::entry:==pid970:oracle:sskgslcas:entry 8eafa97c 0 1 804520c 8045204 fda522f8
1 175725 sskgslcas:return [ 0 0 0 1| 0 0 bc3| 0 0 07a]i=6 PID::entry:==pid970:oracle:sskgslcas:return 8eafa97c 16 1
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 c38| 0 0 07a]i=7 PID::entry:==pid970:oracle:sskgslcas:entry 8ea9cb38 0 1 804520c 8045204 fda522f8
1 175725 sskgslcas:return [ 0 0 0 1| 0 0 c38| 0 0 07a]i=8 PID::entry:==pid970:oracle:sskgslcas:return 8ea9cb38 16 1
1 111575 sskgslcas:entry [ 0 0 0 0| 0 0 bdc| 0 0 07a]i=9 PID::entry:==pid970:oracle:sskgslcas:entry 8ea1d750 0 1 fda52660 fda52658 fda52600
1 175725 sskgslcas:return [ 0 0 0 1| 0 0 bdc| 0 0 07a]i=10 PID::entry:==pid970:oracle:sskgslcas:return 8ea1d750 16 1
1 111575 sskgslcas:entry [ 0 0 0 1| 0 0 01e| 0 0 0 0]i=11 PID::entry:==pid970:oracle:sskgslcas:entry 87d88194 1 35f0000 c030d18 87d88194 888f7c48
1 175725 sskgslcas:return [ 35f 0 0| 0 0 01e| 0 0 0 0]i=12 PID::entry:==pid970:oracle:sskgslcas:return 87d88194 16 1
索引还是占了同样的数据块，所以对应的Latch不变。可以看到，从根块到叶块，再到数据块，竞然都不是独占的，全是共享的，而且都只需要申请一次
。可以用个匿名块验证一下：
declare
myid number;
begin
for i in 1..10000000 loop
select id1 into myid from a2_70m where id1=1;
end loop;
end;
/
和开头的存储过程不同的是，select id1 into myid from a2_70m where id1=1 ，这条语句不再直接用ROWID访问，换成索引。在两个会话中分
别执行此段过程，终查看了一下：
SQL> select event from v$session_event where sid=862;
EVENT
---------------------------------------------
db file sequential read
cursor: pin S wait on X
SQL*Net message to client
SQL*Net message from client
SQL*Net break/reset to client
events in waitclass Other
6 rows selected.
果然没有CBC Latch的竞争。看到没，区别可是非常之大啊。如果不用DTrace分析，恐怕很难准确的发现这点。看来INDEX UNIQUE SCAN和INDEX RANGE
SCAN，不同的访问路径，Oracle实现起来的方法大相庭径啊。而且，由不由的访问路径起始，上层的操作也会不一样。
比如同样是TABLE ACCESS BY INDEX ROWID，下层是INDEX UNIQUE SCAN的话，表块将只有共享Latch。下层是INDEX RANGE SCAN的话，表块上将有独占
Latch。
比较一下索引和非索引的区别：
非
------ -------- ----------------
根 1次共享 1次共享
枝 1次共享 1次共享
叶 1次共享 1次共享 3次独占
表块 1次共享 2次独占
非索引共需8次CBC Latch，其中5次是独占。看来，在读远高于写的环境，想解决CBC Latch竞争问题吗，那就如果可能的话，使用索引吧。
（当然，出现CBC Latch争用，一般都是SQL惹的祸，调SQL即可。这个结论，是说如何从宏观上减少CBC Latch争用）
顺便测一下DML，索引时，即使修改索引列，索引的访问不变，都是共享Latch。但表块是独占Latch。其他UNDO块、DUNO段头了等等Latch的持有访
问，我就不再演示了，有兴趣自己测吧。
其实还有一个问题，就是为什么用Rowid访问一个表块，或者非索引的叶块、表块，Oracle不会以共享的方式获得Latch呢？要解答这个问题，先要
搞清楚一点，为什么用ROWID的形式，访问表块的时候，要申请2次CBC Latch。而根块、枝块只要一次，索引以INDEX UNIQUE SCAN形式访问，所有块都只需
要一次共享的CBC Latch。
这个问题又可以写一篇很长的文章分析了。不知道放在这里是否合适，因为这篇文章已经有点长了。但我觉得，如果你掌握了今天我们所用的方法，继
续这样的分析难度不大。我先简单描述一下，后面再另起一章详细解剖。可以使用我们个脚本：
#!/usr/sbin/dtrace -s -n
dtrace:::BEGIN
{
i=1;
}
pid$1:::entry
{
printf("i=%d PID::entry:==%s:%s:%s:%s %x %x %x %x %x %x",i, probeprov, probemod, probefunc, probename,arg0,arg1,arg2,arg3,arg4,arg5);
i=i+1;
}
拦截所有操作，你可以发现通过ROWID访问，形式如下：
1、调用sskgslcas获得Latch
2、进行一些未知操作
3、调用sskgsldecr释放Latch
4、未知操作
5、memcpy拷贝内存，从SGA向PGA
6、未知操作
7、调用sskgslcas获得Latch
8、进行一些未知操作
9、调用sskgsldecr释放Latch
第5步拷贝内存，其实就是真正的逻辑读过程，把数据从SGA中的Buffer Cache，拷贝到PGA，我跟踪出的Memcpy函数形式如下：
2 172791 memcpy:entry i=663 PID::entry:==pid972:libc.so.1:memcpy:entry fdad1b10 82c61fde 1e fdad2f94 886f2bf8 8045478
第二个参数82c61fde ， 是Buffer Cache中行的位置，我们可以如下确定：
SQL> select file#,dbablk,tch,lower(HLADDR),ba from x$bh where file#=4 and dbablk=20;
FILE# DBABLK TCH LOWER(HL BA
---------- ---------- ---------- -------- --------
4 20 7 8ea1d750 82C60000
BA列，82C60000开始的8K，也就是从82C60000到82C62000，都是4号文件20号块的Buffer。memcpy第二个参数82c61fde，正是在这个范围之间。证明是从
4号文件20号块中拷贝数据。个参数地址fdad1b10，它不在任何内存池地址空间范围之内，它是进程自身的内存，可以认为是PGA。第三个参数1e，十进制是
30，是拷贝数据的长度。查看表的定义：
SQL> desc a2_70m;
Name Null? Type
----------------------------------------- -------- ----------------------------
ID1 NUMBER(38)
ID2 NUMBER(38)
CC1 VARCHAR2(30)
拷贝30个字节，其实就是将CC1列的数据读到PGA中。
另外，还有一点，先说明一下，到下一章再详细讲。上面步骤1至3中间的未知操作，和7至9中的未知操作，其实是加Buffer Pin和释放Buffer Pin。其
实，上面那9个步骤，我们可以简化一下：
1、调用sskgslcas获得独占Latch
2、加Buffer Pin
3、调用sskgsldecr释放Latch
5、memcpy拷贝内存，从SGA向PGA
7、调用sskgslcas获得独占Latch
8、释放Buffer Pin
9、调用sskgsldecr释放Latch
但在索引访问时，形式是这样的：
1、调用sskgslcas获得共享Latch
2、memcpy拷贝内存，从SGA向PGA
3、调用sskgsldecr释放Latch
和ROWID访问的不同之处，没有了Buffer Pin。一个CBC Latch，从逻辑读开始到逻辑读结尾。
为什么索引Root块、枝块的访问，只需要一次共享CBC Latch，叶块、表块需要多次独占。这个问题，现在可以回答了。Oracle认为根块、枝块不会经常
修改，因为，用一个共享CBC Latch，保护逻辑读所有操作。虽然Latch持有时间长，但由于是共享的，不会有争用。而对于叶块和表块，Oracle认为有可能会频
繁修改，所以，用独占Latch保护，获得Buffer Pin，在Pin的保护下，读取、修改Buffer数据。
而至于索引，INDEX UNIQUE SCAN的访问路径，Oracle单独做了处理，也依照根块、枝块的方式访问。这说明如果是索引，对表有大量读写混合
的操作，那么CBC Latch竞争会激烈些，因为没有了Buffer Pin，读持有CBC Latch的时间会较长。但对于读远远多于写的环境，由于读都是共享Latch，反而可以
大大减少CBC Latch的争用。
好了，先到这里吧。已经有点长了。
本章内容，难度稍高，有兴趣的兄弟还是要好好测测。这章内容是后面的基础，如果这一章没问题，那后理解Mutex等等内容就方便了。
由于本章长度有限，有些问题，比如Buffer Pin的问题。我们交到以后解决，这里先提出来，有兴趣可以自己动手分析、测试下。
好，今天就到这里为止了，后续更精彩，敬请期待。
相关文章