DB2 for z和ORACLE关于ROWID的比较

今天正巧看到一篇BLOG，题为《索引组织表中逻辑ROWID的物理猜》，这名字挺新鲜的，作者是yangtingkun，花些功夫看了一下，对理解DB2 for z/OS和ORACLE在这一技术细节上的区别很有收获。

“Oracle的普通表即堆表，存储数据时没有顺序可言，而Oracle的索引组织表是根据主键顺序来存储表中的数据的。”

－－记得第一次得知ORACLE的这个特性时，几欲昏倒，不啻是对数据库世界观的颠覆。意识到原来这两种主流的RDBMS竟然能有如此大的区别。对于ORACLE而言，大多数表的数据存储是没有顺序的；而对于DB2，大多数表的数据存储是按照聚簇索引(Cluster Indxe)来排序的，也就是说，DB2中大多数的表按照ORACLE的分类规则都属于索引组织表。对于DB2，唯一的例外情况就是这个表没有索引——只要哪怕有一个索引，即便这个索引没有被显式地指定为Cluster Index，DB2仍然会尽量按照这个索引的键顺序来存储表中的数据。

[@more@]

“对于普通表而言，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中来的重要。

然而，在DB2的世界，第二个索引，或者叫次索引(Secondary Index)，非聚簇索引（Non-Clustered Index)，仍然是通过记录的ROWID来找到记录的物理位置，没有逻辑ROWID的概念。只是，一个聚簇效率完好（Cluster Ratio=100）的索引，从索引的Leaf page上的entry通过ROWID指向数据data page的关系好比是梳理过的，顺序排列的（如下图上方的索引IX所示）。而非聚簇索引的entry到表data page的关系是乱序的（如下图下方的索引IX2所示）。即便重组，也只会使表的记录按照聚簇索引的顺序重新排列，上方索引的Cluster Ratio=100，而不会使下方非聚簇索引的Cluster Ratio有质的改变。

“对于索引组织表，虽然存储位置可能会经常发生变化，但是主键是必须存在的。如果不能通过物理位置来寻找，那么通过主键来查找也可以找到这条记录。不过Oracle的实现并不是这么简单。 逻辑ROWID除了包含表的主键信息外，还包括了这条记录在索引创建时的物理地址信息。关于逻辑ROWID相信结构描述，可以参考：http://yangtingkun.itpub.net/post/468/11363。而这个地址信息，就是用来实现物理猜的。如果物理猜能够在目标数据块中找到这条记录，那么这个效率和物理ROWID的效率是一样的，只需要一次IO就找到了目标。如果通过物理猜找不到对应的记录，那么Oracle只能通过逻辑ROWID中包含的主键信息，通过主键扫描来定位这条记录，根据索引的层高，这个操作可能会多消耗几次IO操作。”

－－对于DB2，通常情况下，记录的存储位置并不容易发生变化，update也是Position Update为主，尽管这是对cluster规则的一种破坏，但是DB2依靠后端的REORG来进行修复，而换取的好处是记录在前端进行修改的性能。无论是聚簇索引还是非聚簇索引，DB2都通过ROWID来直接定位到记录的物理位置，因此始终是物理ROWID，而无逻辑ROWID的概念。依据引文的观点，ORACLE的次索引的逻辑ROWID包含索引创建时记录的物理位置。但是，当记录发生多次update后，这个逻辑ROWID能命中的概率会显著下降，不得不借助主键（Primary Key）信息再绕回到聚簇索引上去定位数据记录的位置。这里有两个问题值得注意：1，ORACLE为了维护cluster规则，记录进行修改时前端的性能会相对较差；2，即便这样，cluster规则仍然会被破坏，逻辑ROWID的命中率较低，而必须多做几次I/O，也就是从非聚簇索引再绕回聚簇索引。因此，ORACLE对聚簇索引的依赖度更高。

结论：

DB2总是通过ROWID来定位记录的物理位置，无论是聚簇索引还是非聚簇索引都一样；ORACLE通过聚簇索引的ROWID来定位记录的物理位置，非聚簇索引的ROWID也包含主键信息以利用聚簇索引，但是采用了“物理猜”作为一个捷径，即寄希望于记录的物理位置在非聚簇索引创建后不改变。可见，DB2的表数据的存储大多数都是按索引排序的，而ORACLE表数据的存储大多数是无序的（这是多么巨大的差异啊）。对这种索引组织表的应用，会有一些限制（比如更适合只读表，等等），而update性能会较差。

2009.02.04

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

转载于:http://blog.itpub.net/45793/viewspace-1016678/