Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4

Oracle 從9i開始提供了對錶或者分割槽資料壓縮的功能，而11g時，對壓縮排行了細化，可以區別普通操作還是直接路徑操作來決定是否進行壓縮。9i的壓縮更多的面對的是OLAP系統，11g的壓縮也適合於OLTP系統，由於壓縮後，資料位於更少的block內，因此雖然解壓縮可能需要消耗一些時間，但讀取更少的塊所需I/O減少，彌補了效能的不足。按照ORACLE提供的白皮書，壓縮後的資料需要更少的I/O 和CPU 。但我個人認為，壓縮是否真的有效，依賴於被壓縮資料的組成成分和資料量。具體問題具體分析，在對錶進行壓縮之前最好能做個測試。

關於壓縮的使用和效能比較，可以參看《Compressed Tables 》()和《Table Compression Enhancements in Oracle Database 11g Release 1》 () 兩篇文章，Oracle Magazine s上的《Compress to Impress 》() 也做了很詳細的介紹。

在這裡，主要基於Meikel Poess 和Dmitry Potapov 在第 29屆 VLDB 會議(

Berlin, Germany, 2003)提交的《Data Compression in Oracle》。在這篇文章裡，作者介紹了資料壓縮的演算法，並以一個有百萬記錄的表為例，對壓縮和非壓縮的表在裝載、修改/刪除、全表掃描、基於Rowid的讀取等操作在CPU使用和花費時間上進行了比較。

文中介紹到資料的壓縮是基於Block 級的，因此在壓縮率上可能比基於整個庫的壓縮要小，但由於它是自包含的，因此讀取該Block時，就能解壓縮，而無需讀取更多的Block.此外，資料並不是在增刪改時就進行壓縮，而只是達到一定的threshold 後，系統才啟動程式進行壓縮，因此不會影響資料操作的響應時間，有由於壓縮是基於Block的，因此只對該Block進行鎖，從而也不會影響整個系統的效能。

從文章的資料來看，壓縮對於OLAP系統顯然是非常有效份額，但對於OLTP系統，在以後的文章中我將依據我們系統的實際應用進行測試。

ORACLE 壓縮

相關文章