DB2 V9.7 索引壓縮新特性都表現(xiàn)在什么地方？
此文章主要向大家講述的是DB2 V9.7 索引壓縮新特性的正確使用，我們大家都知道DB2 V9.1 數(shù)據(jù)庫其提出了行壓縮技術(shù)，在實際應用中當系統(tǒng)中數(shù)據(jù)量很大，IO 需求超過了磁盤系統(tǒng)提供的容量（即 IO 成為系統(tǒng)的瓶頸）時，行壓縮技術(shù)能夠有效的減少讀寫磁盤的次數(shù)。
DB2 9.7 更進一步提出了索引壓縮技術(shù)，減少索引磁盤空間的占用，減少讀取索引時的 IO 次數(shù)從而提高了性能。
DB2 壓縮不僅有助于減少在線數(shù)據(jù)庫存儲區(qū)需求，還有助于減少在備份和災難恢復時所需的存儲器數(shù)量。此外，由于在備份與恢復過程中涉及到的數(shù)據(jù)量變小了，所以備份與恢復操作所花的時間也就變短了。所有這些因素都在無形中節(jié)約了 IT 成本。
簡介
數(shù)據(jù)庫中占用物理存儲空間的對象主要是表和索引，這兩類對象的大小直接影響著磁盤空間的占用，同時也決定著數(shù)據(jù)庫的性能。當前數(shù)據(jù)庫系統(tǒng)中，隨著時間的推移表會越來越大，對應著索引也會越來越大，這也是我們的系統(tǒng)越來越慢的原因。 DB2 V9.1 中提出了全新的行深度壓縮（deep compression）的技術(shù)，以應對這種挑戰(zhàn)。
盡管深度壓縮的主要目的是節(jié)省存儲空間，但是使用它也可以大大節(jié)省磁盤 I/O 并提高緩沖池命中率。因而可以提高性能，并無需成本——數(shù)據(jù)壓縮和解壓縮需要占用額外的 CPU 周期。深度壓縮的存儲節(jié)省和性能影響與數(shù)據(jù)、數(shù)據(jù)庫本身的設計、數(shù)據(jù)庫調(diào)優(yōu)程度以及應用程序負載有關(guān)。
在 DB2 V9.7，IBM 在行壓縮的基礎上提出了索引壓縮，其目標與行壓縮一樣，都是為減少磁盤空間的占用，這同時適用于大型 OLTP 和數(shù)據(jù)倉庫環(huán)境。 DB2 V9.7 采用多種壓縮算法對索引進行自動壓縮。本文不會對具體的壓縮算法進行討論，而是將重點放在索引壓縮的應用場景上，即如何啟動索引壓縮、什么數(shù)據(jù)分布適合索引壓縮，什么數(shù)據(jù)不適合索引壓縮。
如何啟用索引壓縮
在缺省情況下，當對表啟動壓縮后，索引壓縮也處在啟動狀態(tài)。對于未壓縮的表索引壓縮處于禁用狀態(tài)，我們可以使用 CREATE INDEX 語句的 COMPRESS YES 選項可以更改此缺省行為。創(chuàng)建索引之后，我們還可以使用 ALTER INDEX 語句來啟用或禁用索引壓縮功能；然后，必須執(zhí)行 INDEX REORG 以重建索引。
啟用索引壓縮功能后，DB2 將根據(jù)數(shù)據(jù)庫管理器所選擇的壓縮算法對索引頁在磁盤上和內(nèi)存中的格式進行修改，以便最大程度地減少存儲空間耗用量。根據(jù)所創(chuàng)建索引類型以及索引所包含數(shù)據(jù)的不同，DB2 實現(xiàn)的壓縮程度也會有所變化。例如，通過存儲重復鍵的記錄標識（RID）的縮寫格式，數(shù)據(jù)庫管理器可以對包含大量重復鍵的索引進行壓縮。
在索引鍵前綴的公共程度很高的索引中，數(shù)據(jù)庫管理器可以根據(jù)索引鍵前綴的相似性來進行壓縮。
索引壓縮是使用 CPU 的空閑周期或者是 CPU 在等待 IO 時的周期對索引數(shù)據(jù)進行壓縮、解壓縮的。因此在帶來 IO 成本節(jié)約的同時，索引壓縮技術(shù)增加了系統(tǒng)的 CPU 負擔，如果我們的系統(tǒng)不受到 CPU 的約束，我們在對數(shù)據(jù)進行 Select、Insert、Update 時都能感覺到索引壓縮技術(shù)帶來的性能提升。
如果我們的系統(tǒng)本身 CPU 就已經(jīng)比較繁忙了，再啟用索引壓縮可能會帶來一些負面影響。
清單 1. 創(chuàng)建表時指定表壓縮
- db2 "create table t1 (col1 int) compress yes"
- db2 "create index idx_col1 on t1(col1) "
- db2 "select substr(INDNAME,1,18),substr(TABNAME,1,18),COMPRESSION,PCTPAGESSAVED
- from syscat.indexes where tabname='T1'"
- 1 2
- COMPRESSION PCTPAGESSAVED
- IDX_COL1 T1 Y -1
上面的語句中首先創(chuàng)建了一張表 T1，并對該表啟動行壓縮。在創(chuàng)建索引 idx_col1 時，由于基表啟動了壓縮，索引壓縮也被自動啟動。上述代碼的第三句就是驗證索引 idx_col1 確實啟動了壓縮，而由于未收集統(tǒng)計信息因此當前壓縮比例是 -1 。當我們向表中 Insert 或者 Update 數(shù)據(jù)時，索引自動被壓縮維護到物理存儲上。
如果我們在創(chuàng)建表時未指定表進行壓縮，那么此表上創(chuàng)建的索引默認情況下是不壓縮的，如果期望對索引進行壓縮需要進行以下步驟。
- db2 "create table t2 (col1 int)
- db2 "create index idx_col2 on t2(col1) "
- db2 "select substr(INDNAME,1,18),substr(TABNAME,1,18),COMPRESSION,PCTPAGESSAVED
- from syscat.indexes where tabname='T2'"
- 1 2 COMPRESSION PCTPAGESSAVED
- IDX_COL2 T2 N
- -1
- db2 "alter index idx_col2 compress yes"
- db2 "select substr(INDNAME,1,18),substr(TABNAME,1,18),COMPRESSION,PCTPAGESSAVED
- from syscat.indexes where tabname='T2'"
- 1 2 COMPRESSION PCTPAGESSAVED
- IDX_COL2 T2 Y -1
上面語句中開始創(chuàng)建表時未指定表進行壓縮，后繼創(chuàng)建的索引默認情況下不壓縮。如果希望索引啟動壓縮功能，則可以使用 alter 語句進行更改。
注意，即使我們更改將索引更改為壓縮后，后來插入的數(shù)據(jù)還是未壓縮的，直到我們使用 reorg 語句重組索引。 DB2 考慮中間更改索引的壓縮屬性，需要對更改前、更改后的插入的數(shù)據(jù)保持一致性，不可能在索引中同時存在非壓縮、壓縮數(shù)據(jù)。
我們對上面的 IDX_COL2 執(zhí)行以下腳本，插入 1 萬行數(shù)據(jù)：
- INSERT INTO t2 (col1)
- WITH TEMP (COUNTER, col1) AS
- (
- VALUES (0, INT(RAND() * 1000))
- UNION ALL
- SELECT
- (COUNTER + 1), INT(RAND() * 1000)
- FROM
- TEMP
- WHERE
- (COUNTER + 1) < 10000
- )
- SELECT
- col1
- FROM
- TEMP
- ;
然后我們收集表和索引的統(tǒng)計信息。
- db2 "runstats on table db2admin.t2 and indexes all"
- db2 "select substr(INDNAME,1,18),substr(TABNAME,1,18),COMPRESSION,PCTPAGESSAVED
- from syscat.indexes where tabname='T2'"
- 1 2 COMPRESSION PCTPAGESSAVED
- IDX_COL2 T2 Y 0
大家會發(fā)現(xiàn)壓縮率為 0，這是因為我們還沒有對索引進行 reorg 。當然，除了上面 Select 語句我們也可以使用 REORGCHK 工具檢查是否需要對索引進行 Reorg 。
- db2 "reorg indexes all for table db2admin.t2"
- db2 "runstats on table db2admin.t2 and indexes all"
- db2 "select substr(INDNAME,1,18),substr(TABNAME,1,18),COMPRESSION,PCTPAGESSA
- VED from syscat.indexes where tabname='T2'"
- 1 2 COMPRESSION PCTPAGESSAVED
- IDX_COL2 T2 Y 40
以上的相關(guān)內(nèi)容就是對DB2 V9.7 索引壓縮新特性的使用的介紹，望你能有所收獲。
【編輯推薦】
