深入剖析-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所带来的“去重”
原文发布时间为：2017-09-18
作者：崔华
本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”微信公众号