深入剖析-Oracle索引分支块的结构

作者介绍

崔华 网名 dbsnake

Oracle ACE Director，ACOUG 核心专家

重要结论

1、每个索引分支块都只有一个lmc，这个lmc指向的分支块/叶子块中的所有索引键值列中的最大值一定小于该lmc所在分支块的所有索引键值列中的最小值；

2、索引分支块的行记录所对应的存储格式为“行头 + 分支块/叶子块的RDBA + col 0 + col 1”，其中col 0为索引键值列，等于该行行头“分支块/叶子块的RDBA”所指向的叶子块中的第一行索引行所对应的数据行的ROWID

实例解析

通过实例解析Oracle索引分支块的结构

/nbstu01/app/oracle/diag/rdbms/nbstest/NBSTEST/trace/NBSTEST_ora_9699378.trc的内容为如下所示：

从上述显示内容中我们可以看出，现在索引IDX_T2有如下这三个分支块：

我们现在直接来dump上述分支块0x38003c6，dump后的trace文件内容为如下所示：

先来看上述显示内容中的第9行记录：

上述第9行记录所在叶子块的起止地址为0x380028f：

上述叶子块的dump内容为如下所示：

然后我们再来dump上述叶子块的前一个块（即kdxleprv 58720910=0x380028e）；

也就是说上述第9行记录对应了两个索引行，这两个索引行恰好分布在两个叶子块中，一个在叶子块0x0380028f中，一个在叶子块0x380028e中

再来看上述分支块的dump内容中的第20行记录：

上述第20行记录所在叶子块的起始地址为0x380029a：

上述叶子块的dump内容为如下所示：

然后我们再来dump上述叶子块的前一个块（即58720921=0x3800299）；

也就是说上述第20行记录对应了两个索引行，这两个索引行也恰好分布在两个叶子块中，一个在叶子块0x0380029a中，一个在叶子块0x03800299中

再来看上述分支块dump内容中的第230行记录：

因分析过程和结论和上述类似，这里略去。

col1记录的值为其ROWID头3个byte的实例

上述分支块的行记录所对应叶子块的dump内容为如下所示：

再来dump上述叶子块的前一个块：

这里上述叶子块的第一行记录所对应的ROWID为01 43 d1 fd 00 2b，其前一个叶子块的最后一行记录所对应的ROWID为01 43 d0 11 00 91，这两个ROWID的头3个byte分别为01 43 d1和01 43 d0，已然不同，所以上述分支块的行记录的col1只用记录01 43 d1就可以了。

col1记录的值为其ROWID头1个byte的实例

row#18[7464] dba: 184552472=0xb000c18 col 0; len 20; (20): 2f 31 62 39 34 37 31 65 38 5f 53 69 67 6e 61 74 75 72 65 31 col 1; len 1; (1): 0b

上述分支块的行记录所对应叶子块的dump内容为如下所示：

再来dump上述叶子块的前一个块：

这里上述叶子块的第一行记录所对应的ROWID为0b 00 0b 6a 00 57，其前一个叶子块的最后一行记录所对应的ROWID为01 43 d1 a7 00 06，这两个ROWID的头1个byte分别为0b和01，已然不同，所以上述分支块的行记录的col1只用记录0b就可以了。

常见问题

sys.undump存储过程的源码能否提供下？

create or replace procedure undump
(i_vc_input in varchar2) is
/*

功能： 将dump出来的16进制文本内容翻译成其原始文本，目前仅支持ZHS16GBK和AL32UTF8字符集 作者： dbsnake 创建日期：2010-11-30

输入参数： i_vc_input: 输入的dump出来的16进制文本内容

输出参数： 无

输入输出参数： 无

调用到的存储过程： 无

sys.cdba()是否是系统自带的

不是，CDBA的源码如下：

关于oracle自定义外连接”(+)” 书中写的关于full outer join的等价改写：

您提到Oracle断然不会采用这样的等价改写，而是通过如下的改写：

通过这两种改写方式得到的结果是一致的，并查看了两种改写的执行计划，只是在第一种方式中多了union的排序操作，是因为这个原因吗？

排序只是union的副作用，这里为什么用union来模拟是因为我需要union所带来的“去重”