我正在侵占Richard Foote（译者注：ORACLE 索引专家）的领地——计划写一些关于Oracle B树索引实现的细节。不过，我的策略是，在给出答案之前，先问几个可能会引发一些猜测的问题，以此来使大家有兴趣。所以…
对系统上的特定索引运行validate index之后，我从视图index_stats中选择以下列：（使用Tom Kyte宝贵的“每行一列”例程）。
BLOCKS : 640
LF_ROWS : 100008
LF_BLKS : 601
LF_ROWS_LEN : 1900152
LF_BLK_LEN : 3992
DEL_LF_ROWS : 0
DEL_LF_ROWS_LEN : 0
DISTINCT_KEYS : 100008
MOST_REPEATED_KEY : 1
BTREE_SPACE : 2423288
USED_SPACE : 1908481
PCT_USED : 79
观察以上结果，你对重建这个索引有什么看法吗？
1、绝对不需要
2、很可能不需要
3、倾向于不需要
4、信息不足
5、倾向于需要
6、很可能需要
7、肯定需要
别忘了证明你的看法。
作为一个额外的问题-你认为我的块大小是什么？
附注（或者可能用得上的附注）：Richard Foote 不许回答这个问题–他可能知道我要用这一系列贴子做什么。
更新：我的最终答案在评论9处。
Update: My final answer is in comment 9.
以下附评论9内容：
如Chris(人名）所说，正确的答案是“4、信息不足”。显然，我可以说（正如Chirs指出的那样），如果你不知道索引是如何使用的，为什么它存在，你就不知道重建它是否有任何好处；但除此之外，我没有向你展示一些你真正需要知道的,来自于index_stats的数字数据：
BR_ROWS : 600
BR_BLKS : 3
BR_ROWS_LEN : 8329
BR_BLK_LEN : 8032
如果你没有上述关于分支块的信息，索引看起来的块大小是4KB（如Hemant和Asif（人名）所说），而且使用率是80%，这个指标是“随机到达B树”（译者注：意为插入到该索引的值是随机的）的平均值。这个80%的数值将答案推向了“2、很可能不需要”
但是，当叶子块的长度好象让我们认为块大小为4KB时，分支块的长度如何会有8032的值（这意味着块大小是8KB）–除非像Chris，你非常熟悉一些关键的数值。
块长度指出了当块满足所有管理开销后可用的空间；而这些管理开销就包括事务槽（ITL)，在本例中，在很多块中，（ITL的数量）恰巧达到了一个8KB的块所能达到的最大值–169。显然，从创建表的那一刻起，索引就受到了大量并发DML的影响。根据最坏情况下的ITL大小，validate命令计算出叶块的可用空间为（8048–169*24）=3992字节。因此，索引条目似乎非常有效地使用了可用空间（80%），但是每个块在ITL条目数量上，有一个非同寻常的开销。
注：当一个事务槽长时间占用时，DML不需要有一个高的发生频率（例如，每秒事务数）出现，只要有一些事务保持未提交状态足够长的时间，使其活动重叠即可。例如，如果您每分钟只执行180个事务，但每五分钟提交一次事务，那么一个块上的活动事务数（即ITL条目数）将有大量时间增长到169。（只要对于堆表和索引组织表而言，这仅仅是一个参数，就要对如何使用“选择记录准备更新、鼓捣一段时间、更新、提交”这样的代码提高警惕）
如果你coalesce(或rebuild)这个索引，则过多的ITL条目会消失，并下降到initrans参数所定义的每个叶子块的大小。
但是，你应该做coalesce吗？
如果高并发度仅仅出现在你插入数据时，那么这也许是个好主意–并且这只与Asif所推测的右向索引（原文为right-hand index 译者注：我理解为右侧单调递增）相关。
如果高并发度还出现在随后的数据修改和删除中，那么coalesce索引可能就是一个不好的主意了。你也许会发现当coalesce完成后，索引为了容纳必需的ITL条目，索引空间会灾难性的爆炸增长。（如果在叶子块中需要额外的ITL条目时，Oracle甚至会对一个简单的删除操作做叶子块的分裂–索引上的ITL管理与表上的ITL管理非常不一样。）
所以，根据额外提供的数据（或者你知道表空间中的块大小），正确的答案是“4、信息不足”。因为我们可以看到索引中发生了一些非同寻常的事情，我们需要进一步调查–我们将在索引测验2（点此链接）中开始这样做。
原文链接和内容如下：
链接：https://jonathanlewis.wordpress.com/2009/07/20/index-quiz-1/
I’m encroaching on Richard Foote’s territory here – with plans to write a few details about some of the implementation details of Oracle’s B-tree indexes. My strategy, though, is to entertain by asking a few questions that might prompt a little speculation before giving some answers. So …
After running validate index against a particular index on my system, I select the following columns from view index_stats: (using Tom Kyte’s invaluable “one column per line” routine).
HEIGHT : 3
BLOCKS : 640
LF_ROWS : 100008
LF_BLKS : 601
LF_ROWS_LEN : 1900152
LF_BLK_LEN : 3992
DEL_LF_ROWS : 0
DEL_LF_ROWS_LEN : 0
DISTINCT_KEYS : 100008
MOST_REPEATED_KEY : 1
BTREE_SPACE : 2423288
USED_SPACE : 1908481
PCT_USED : 79
Looking at these results, what would your opinion be about rebuilding this index ?
Definitely not
Probably not
Small bias against
Insufficient information
Small bias for
Probably would
Definitely would
Don’t forget to justify your opinion.
As a bonus question – what do you think my blocksize was ?
Footnote (or possibly Foote note): Richard Foote is not allowed to answer the question – as he probably knows where I am going with this set of posts.
Update: My final answer is in comment 9.
