DB2 V9.7 索引壓縮新特性都表現在什么地方？
此文章主要向大家講述的是DB2 V9.7 索引壓縮新特性的正確使用，我們大家都知道DB2 V9.1 數據庫其提出了行壓縮技術，在實際應用中當系統中數據量很大，IO 需求超過了磁盤系統提供的容量（即 IO 成為系統的瓶頸）時，行壓縮技術能夠有效的減少讀寫磁盤的次數。
DB2 9.7 更進一步提出了索引壓縮技術，減少索引磁盤空間的占用，減少讀取索引時的 IO 次數從而提高了性能。
DB2 壓縮不僅有助于減少在線數據庫存儲區需求，還有助于減少在備份和災難恢復時所需的存儲器數量。此外，由于在備份與恢復過程中涉及到的數據量變小了，所以備份與恢復操作所花的時間也就變短了。所有這些因素都在無形中節約了 IT 成本。
簡介
數據庫中占用物理存儲空間的對象主要是表和索引，這兩類對象的大小直接影響著磁盤空間的占用，同時也決定著數據庫的性能。當前數據庫系統中，隨著時間的推移表會越來越大，對應著索引也會越來越大，這也是我們的系統越來越慢的原因。 DB2 V9.1 中提出了全新的行深度壓縮（deep compression）的技術，以應對這種挑戰。
盡管深度壓縮的主要目的是節省存儲空間，但是使用它也可以大大節省磁盤 I/O 并提高緩沖池命中率。因而可以提高性能，并無需成本——數據壓縮和解壓縮需要占用額外的 CPU 周期。深度壓縮的存儲節省和性能影響與數據、數據庫本身的設計、數據庫調優程度以及應用程序負載有關。
在 DB2 V9.7，IBM 在行壓縮的基礎上提出了索引壓縮，其目標與行壓縮一樣，都是為減少磁盤空間的占用，這同時適用于大型 OLTP 和數據倉庫環境。 DB2 V9.7 采用多種壓縮算法對索引進行自動壓縮。本文不會對具體的壓縮算法進行討論，而是將重點放在索引壓縮的應用場景上，即如何啟動索引壓縮、什么數據分布適合索引壓縮，什么數據不適合索引壓縮。
如何啟用索引壓縮
在缺省情況下，當對表啟動壓縮后，索引壓縮也處在啟動狀態。對于未壓縮的表索引壓縮處于禁用狀態，我們可以使用 CREATE INDEX 語句的 COMPRESS YES 選項可以更改此缺省行為。創建索引之后，我們還可以使用 ALTER INDEX 語句來啟用或禁用索引壓縮功能；然后，必須執行 INDEX REORG 以重建索引。
啟用索引壓縮功能后，DB2 將根據數據庫管理器所選擇的壓縮算法對索引頁在磁盤上和內存中的格式進行修改，以便最大程度地減少存儲空間耗用量。根據所創建索引類型以及索引所包含數據的不同，DB2 實現的壓縮程度也會有所變化。例如，通過存儲重復鍵的記錄標識（RID）的縮寫格式，數據庫管理器可以對包含大量重復鍵的索引進行壓縮。
在索引鍵前綴的公共程度很高的索引中，數據庫管理器可以根據索引鍵前綴的相似性來進行壓縮。
索引壓縮是使用 CPU 的空閑周期或者是 CPU 在等待 IO 時的周期對索引數據進行壓縮、解壓縮的。因此在帶來 IO 成本節約的同時，索引壓縮技術增加了系統的 CPU 負擔，如果我們的系統不受到 CPU 的約束，我們在對數據進行 Select、Insert、Update 時都能感覺到索引壓縮技術帶來的性能提升。
如果我們的系統本身 CPU 就已經比較繁忙了，再啟用索引壓縮可能會帶來一些負面影響。
清單 1. 創建表時指定表壓縮
- 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
上面的語句中首先創建了一張表 T1，并對該表啟動行壓縮。在創建索引 idx_col1 時，由于基表啟動了壓縮，索引壓縮也被自動啟動。上述代碼的第三句就是驗證索引 idx_col1 確實啟動了壓縮，而由于未收集統計信息因此當前壓縮比例是 -1 。當我們向表中 Insert 或者 Update 數據時，索引自動被壓縮維護到物理存儲上。
如果我們在創建表時未指定表進行壓縮，那么此表上創建的索引默認情況下是不壓縮的，如果期望對索引進行壓縮需要進行以下步驟。
- 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
上面語句中開始創建表時未指定表進行壓縮，后繼創建的索引默認情況下不壓縮。如果希望索引啟動壓縮功能，則可以使用 alter 語句進行更改。
注意，即使我們更改將索引更改為壓縮后，后來插入的數據還是未壓縮的，直到我們使用 reorg 語句重組索引。 DB2 考慮中間更改索引的壓縮屬性，需要對更改前、更改后的插入的數據保持一致性，不可能在索引中同時存在非壓縮、壓縮數據。
我們對上面的 IDX_COL2 執行以下腳本，插入 1 萬行數據：
- 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
- ;
然后我們收集表和索引的統計信息。
- 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
大家會發現壓縮率為 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
以上的相關內容就是對DB2 V9.7 索引壓縮新特性的使用的介紹，望你能有所收獲。
【編輯推薦】
