索引的5-5分裂RAC环境下一个有趣的“副作用”

索引的5-5分裂RAC环境下一个有趣的“副作用”
索引的分裂，依据分裂后2个索引块上分布的数据比例，分为5-5分裂和9-1分裂：
•    5-5分裂：新旧2个数据块上的数据基本相等；
•    9-1分裂：大部分数据还在原有数据块上，只有少量数据被转移到新的数据块上。

这里不会详细介绍索引分裂的方方面面。只会挑跟本文有关的做介绍。

有一种情况会发生索引的9-1分裂：
当事务向索引中最后一个叶子节点数据块上插入一条大于或等于（ROWID大于最大值的ROWID）数据块上最大值的数据，且该数据块上不存在其它未提交事务时，此时如果没有足够空间，就会发生9-1分裂：即分裂时，绝大部分数据保留在原有节点数据块上，仅少量数据被转移到新数据块上。

这种9-1分裂发生的场景再适合不过依据序列自增的键值了，总是满足当前插入的值总是当前索引的最大值。

可是RAC环境下，此类索引发生的分裂方式，可能不是9-1分裂，而是5-5分裂。
来举个例子就明白了。

一张有频繁插入操作的业务表，其表的主键ID依据序列SEQ_ID来产生ID值，为了优化性能，你设置的序列的CACHE为3000（对于频繁插入的表，这个CACHE值一点不大）。
假设你是有3个节点的RAC环境。

节点一取到的序列值是：2000-5000
节点二取到的序列值是：5001-8000
节点三取到的序列值是：8001-11000

由于每个节点间取到的序列值跨度比较大，而对于索引这种有序结构来说，三个节点插入的索引叶子块不在一个索引块的可能性就很大（可能性大小跟你设置的cache值大小有关系，因为节点1，插入的值是2000，节点2插入的值是5001，节点3插入的值是8001，跨度很大，导致不在一个索引叶子块，而是分散在3个块里）

这种情况下，相当于每个节点其实都各自维护自己的索引叶子节点，节点2往节点1的索引叶子上插入数据的可能性很小，同理节点3往节点2插入数据的可能性比较小，更不可能往节点1插入数据。
这种情况下，节点1和节点2上的索引叶子节点，发生的是5-5分裂，因为，因为
节点1和节点2，每次插入新值的时候，虽然是当前叶子节点的最大值，但是却不是整个索引的最大值，只有节点3发生的分裂是9-1分裂，每次节点3插入的数据都是整个索引的最大值。
这种情况导致的副作用就是索引变得比单实例下大了很多，节点数越多，这种情况越明显。
随着数据的增长，这种5-5分裂可能会发生在任何一个节点，这取决于哪个节点取到了序列的最大范围，取到最大范围的发生9-1分裂，否则5-5分裂。
这种情况下5-5分裂，空间浪费严重，因为这些空间，除非索引重建，否则，永远不会被用到了，因为这是一个自增的索引。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-764357/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-764357/