摘要：本文主要要介绍Oracle与DB2数据存储模式的相关知识，让我们一起来了解一下这部分内容吧。“Oracle的普通表即堆表，存储数据时没有顺序可言，而Oracle的索引组织表是根据主键顺序来存储表中的数据的。”

　　记得第一次得知Oracle的这个特性时，几欲昏倒，不啻是对数据库世界观的颠覆。意识到原来这两种主流的RDBMS竟然能有如此大的区别。对于Oracle而言，大多数表的数据存储是没有顺序的;而对于DB2，大多数表的数据存储是按照聚簇索引(Cluster Indxe)来排序的，也就是说，DB2中大多数的表按照Oracle的分类规则都属于索引组织表。

　　对于DB2，唯一的例外情况就是这个表没有索引——只要哪怕有一个索引，即便这个索引没有被显式地指定为Cluster Index，DB2仍然会尽量按照这个索引的键顺序来存储表中的数据。
　　“对于普通表而言，Oracle保证数据插入到表中之后，数据的物理地址ROWID不会再发生改变。当然对表进行MOVE，或者ENABLE ROW MOVEMENT之后对分区表的分区键值进行修改等明确导致表数据位置发生变化的操作除外。也就是说，普通的增、删、改不会导致现有记录的物理地址发生变化。

　　即使记录的长度发生了变化，导致当前数据块中无法容纳这条记录，Oracle也会在原位置上留下一个ROWID信息，通过这个ROWID信息可以找到这条记录的新的位置。这也就是行迁移、行链接的实现方式。虽然增加了额外的IO，但是确保了ROWID不发生变化。”

　　这就是所谓的Position Update，即普通的Update不会改变记录的物理位置。当然也有例外，那就是：

　　1，记录所属表分区改变，那么记录肯定要移动到目标分区对应的物理文件中，位置改变在所难免;

　　2，记录本身是变长记录，这里的变长是指“物理变长”，不仅指含有变长字段(Variable Length)的记录，而且也指表属性为COMPRESS YES的记录(因为DB2 z的DATA COMPRESS是ROW COMPRESS)，当变长记录Update时，物理长度可能会变化，通常缩短都没问题，仍然可以做到Position Update，但是如果增长的话，有可能原来的物理位置没有足够的空间存放增长后的记录，所以记录只能重新去寻找一个合适的空间安身，而在原来的物理位置存放一个指向新位置的指针(当然，指针本身肯定很短，原位置足够存放得下)，这就称为Overflow。

　　也就是原来ROWID指向的物理位置是一个指针，指针指向新位置(或者也可能指向另一个指针，但最终会指向记录实际的物理位置，从而形成一个较长的指针链(Pointer Chain)，当然这种情况对性能的伤害会更大)。

　　“可以看到，前面提到的MOVE，以及一些导致ROWID发生变化的分区操作，在使得ROWID变化的同时，也会导致索引处于不可用状态。”

　　问题来了。ROWID变化怎么会导致索引处于不可用状态呢？在DB2中，记录的物理位置变化，或者ROWID的改变，对应的Index Entry会跟着改变。换句话说，如果一个update涉及索引字段(index key columns)的改变，那么这个update至少包含两部分内容，即对表的更新和对索引的更新。

　　“那么现在存在一个问题，对于索引组织表而言，为了保证数据存储是根据主键顺序进行的，就必须根据数据的增、删、改随时调整表中数据的位置，这使得ROWID不发生改变这个前提无法实现。而对于索引组织表，第二个索引需要一个方法来找到表中数据的具体位置，因此也就有了逻辑ROWID。”

　　技术的差异体现在这里了。对索引组织表，Oracle严格保证数据存储按索引顺序排列，也就是说在记录修改时，在前端就调整记录的位置。而DB2则不然，DB2是尽量去保证数据按照索引顺序排列(聚簇)，但并不严格和强求，记录如果不能存放到最佳位置(按索引排序的理想位置)，可以存放到附近的次佳位置或偏离最佳位置更远。随着记录修改越多，聚簇的效率(Cluster Ratio)也就越差，所以需要重组(REORG utility)，也就是DB2在后端通过重组来调整记录的位置。因此，REORG在DB2中远比Oracle中来的重要。

　　责任编辑：Lily