Oracle與DB2數(shù)據(jù)存儲模式的區(qū)別詳解
Oracle與DB2數(shù)據(jù)存儲模式的相關(guān)知識是本文我們主要要介紹的內(nèi)容，接下來就讓我們一起來了解一下這部分內(nèi)容吧。“Oracle的普通表即堆表，存儲數(shù)據(jù)時(shí)沒有順序可言，而Oracle的索引組織表是根據(jù)主鍵順序來存儲表中的數(shù)據(jù)的。”
記得***次得知Oracle的這個(gè)特性時(shí)，幾欲昏倒，不啻是對數(shù)據(jù)庫世界觀的顛覆。意識到原來這兩種主流的RDBMS竟然能有如此大的區(qū)別。對于Oracle而言，大多數(shù)表的數(shù)據(jù)存儲是沒有順序的；而對于DB2，大多數(shù)表的數(shù)據(jù)存儲是按照聚簇索引(Cluster Indxe)來排序的，也就是說，DB2中大多數(shù)的表按照Oracle的分類規(guī)則都屬于索引組織表。
對于DB2，唯一的例外情況就是這個(gè)表沒有索引——只要哪怕有一個(gè)索引，即便這個(gè)索引沒有被顯式地指定為Cluster Index，DB2仍然會盡量按照這個(gè)索引的鍵順序來存儲表中的數(shù)據(jù)。
“對于普通表而言，Oracle保證數(shù)據(jù)插入到表中之后，數(shù)據(jù)的物理地址ROWID不會再發(fā)生改變。當(dāng)然對表進(jìn)行MOVE，或者ENABLE ROW MOVEMENT之后對分區(qū)表的分區(qū)鍵值進(jìn)行修改等明確導(dǎo)致表數(shù)據(jù)位置發(fā)生變化的操作除外。也就是說，普通的增、刪、改不會導(dǎo)致現(xiàn)有記錄的物理地址發(fā)生變化。
即使記錄的長度發(fā)生了變化，導(dǎo)致當(dāng)前數(shù)據(jù)塊中無法容納這條記錄，Oracle也會在原位置上留下一個(gè)ROWID信息，通過這個(gè)ROWID信息可以找到這條記錄的新的位置。這也就是行遷移、行鏈接的實(shí)現(xiàn)方式。雖然增加了額外的IO，但是確保了ROWID不發(fā)生變化。”
這就是所謂的Position Update，即普通的Update不會改變記錄的物理位置。當(dāng)然也有例外，那就是：
1，記錄所屬表分區(qū)改變，那么記錄肯定要移動到目標(biāo)分區(qū)對應(yīng)的物理文件中，位置改變在所難免；
2，記錄本身是變長記錄，這里的變長是指“物理變長”，不僅指含有變長字段（Variable Length）的記錄，而且也指表屬性為COMPRESS YES的記錄（因?yàn)镈B2 z的DATA COMPRESS是ROW COMPRESS），當(dāng)變長記錄Update時(shí)，物理長度可能會變化，通常縮短都沒問題，仍然可以做到Position Update，但是如果增長的話，有可能原來的物理位置沒有足夠的空間存放增長后的記錄，所以記錄只能重新去尋找一個(gè)合適的空間安身，而在原來的物理位置存放一個(gè)指向新位置的指針（當(dāng)然，指針本身肯定很短，原位置足夠存放得下），這就稱為Overflow。
也就是原來ROWID指向的物理位置是一個(gè)指針，指針指向新位置（或者也可能指向另一個(gè)指針，但最終會指向記錄實(shí)際的物理位置，從而形成一個(gè)較長的指針鏈（Pointer Chain），當(dāng)然這種情況對性能的傷害會更大）。
“可以看到，前面提到的MOVE，以及一些導(dǎo)致ROWID發(fā)生變化的分區(qū)操作，在使得ROWID變化的同時(shí)，也會導(dǎo)致索引處于不可用狀態(tài)。”
問題來了。ROWID變化怎么會導(dǎo)致索引處于不可用狀態(tài)呢？在DB2中，記錄的物理位置變化，或者ROWID的改變，對應(yīng)的Index Entry會跟著改變。換句話說，如果一個(gè)update涉及索引字段（index key columns）的改變，那么這個(gè)update至少包含兩部分內(nèi)容，即對表的更新和對索引的更新。
“那么現(xiàn)在存在一個(gè)問題，對于索引組織表而言，為了保證數(shù)據(jù)存儲是根據(jù)主鍵順序進(jìn)行的，就必須根據(jù)數(shù)據(jù)的增、刪、改隨時(shí)調(diào)整表中數(shù)據(jù)的位置，這使得ROWID不發(fā)生改變這個(gè)前提無法實(shí)現(xiàn)。而對于索引組織表，第二個(gè)索引需要一個(gè)方法來找到表中數(shù)據(jù)的具體位置，因此也就有了邏輯ROWID。”
技術(shù)的差異體現(xiàn)在這里了。對索引組織表，Oracle嚴(yán)格保證數(shù)據(jù)存儲按索引順序排列，也就是說在記錄修改時(shí)，在前端就調(diào)整記錄的位置。而DB2則不然，DB2是盡量去保證數(shù)據(jù)按照索引順序排列（聚簇），但并不嚴(yán)格和強(qiáng)求，記錄如果不能存放到***位置（按索引排序的理想位置），可以存放到附近的次佳位置或偏離***位置更遠(yuǎn)。隨著記錄修改越多，聚簇的效率（Cluster Ratio）也就越差，所以需要重組（REORG utility)，也就是DB2在后端通過重組來調(diào)整記錄的位置。因此，REORG在DB2中遠(yuǎn)比Oracle中來的重要。
然而，在DB2的世界，第二個(gè)索引，或者叫次索引(Secondary Index)，非聚簇索引（Non-Clustered Index)，仍然是通過記錄的ROWID來找到記錄的物理位置，沒有邏輯ROWID的概念。只是，一個(gè)聚簇效率完好（Cluster Ratio=100）的索引，從索引的Leaf page上的entry通過ROWID指向數(shù)據(jù)data page的關(guān)系好比是梳理過的，順序排列的（如下圖上方的索引IX所示）。而非聚簇索引的entry到表data page的關(guān)系是亂序的（如下圖下方的索引IX2所示）。即便重組，也只會使表的記錄按照聚簇索引的順序重新排列，上方索引的Cluster Ratio=100，而不會使下方非聚簇索引的Cluster Ratio有質(zhì)的改變。
“對于索引組織表，雖然存儲位置可能會經(jīng)常發(fā)生變化，但是主鍵是必須存在的。如果不能通過物理位置來尋找，那么通過主鍵來查找也可以找到這條記錄。不過Oracle的實(shí)現(xiàn)并不是這么簡單。 邏輯ROWID除了包含表的主鍵信息外，還包括了這條記錄在索引創(chuàng)建時(shí)的物理地址信息。關(guān)于邏輯ROWID相信結(jié)構(gòu)描述，可以參考：http://yangtingkun.itpub.net/post/468/11363。而這個(gè)地址信息，就是用來實(shí)現(xiàn)物理猜的。
如果物理猜能夠在目標(biāo)數(shù)據(jù)塊中找到這條記錄，那么這個(gè)效率和物理ROWID的效率是一樣的，只需要一次IO就找到了目標(biāo)。如果通過物理猜找不到對應(yīng)的記錄，那么Oracle只能通過邏輯ROWID中包含的主鍵信息，通過主鍵掃描來定位這條記錄，根據(jù)索引的層高，這個(gè)操作可能會多消耗幾次IO操作。”
對于DB2，通常情況下，記錄的存儲位置并不容易發(fā)生變化，update也是Position Update為主，盡管這是對cluster規(guī)則的一種破壞，但是DB2依靠后端的REORG來進(jìn)行修復(fù)，而換取的好處是記錄在前端進(jìn)行修改的性能。無論是聚簇索引還是非聚簇索引，DB2都通過ROWID來直接定位到記錄的物理位置，因此始終是物理ROWID，而無邏輯ROWID的概念。依據(jù)引文的觀點(diǎn)，Oracle的次索引的邏輯ROWID包含索引創(chuàng)建時(shí)記錄的物理位置。
但是，當(dāng)記錄發(fā)生多次update后，這個(gè)邏輯ROWID能命中的概率會顯著下降，不得不借助主鍵（Primary Key）信息再繞回到聚簇索引上去定位數(shù)據(jù)記錄的位置。這里有兩個(gè)問題值得注意：
1，Oracle為了維護(hù)cluster規(guī)則，記錄進(jìn)行修改時(shí)前端的性能會相對較差；
2，即便這樣，cluster規(guī)則仍然會被破壞，邏輯ROWID的命中率較低，而必須多做幾次I/O，也就是從非聚簇索引再繞回聚簇索引。因此，Oracle對聚簇索引的依賴度更高。
結(jié)論：
DB2總是通過ROWID來定位記錄的物理位置，無論是聚簇索引還是非聚簇索引都一樣；Oracle通過聚簇索引的ROWID來定位記錄的物理位置，非聚簇索引的ROWID也包含主鍵信息以利用聚簇索引，但是采用了“物理猜”作為一個(gè)捷徑，即寄希望于記錄的物理位置在非聚簇索引創(chuàng)建后不改變。
可見，DB2的表數(shù)據(jù)的存儲大多數(shù)都是按索引排序的，而Oracle表數(shù)據(jù)的存儲大多數(shù)是無序的（這是多么巨大的差異?。@種索引組織表的應(yīng)用，會有一些限制（比如更適合只讀表，等等），而update性能會較差。
關(guān)于Oracle與DB2數(shù)據(jù)存儲模式的區(qū)別的相關(guān)知識就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！
【編輯推薦】
