新インデックスの検証 その２
＜新インデックスの検証 その２＞ ペンネーム モンキーターン
今回は、前回お話した「夢？のようなインデックス」（以下、夢イン）を実際
に作成してみる。
Index Skip Scans機能により、Oracle8i以前は複数のインデックスが必要だっ
たものを1つの複合インデックスで作成して、作成時に圧縮する。
インデックス検索時間は変わらず、インデックス領域は大幅に削減され、DML
処理も大幅に向上し、メンテナンスも楽になる？
インデックスの圧縮を行なうことにより、作成時間・領域使用サイズにどのよ
うな変化が起こるのであろうか？
検証スタート！！！
検証用テーブル( verification, verification2 )を作成する。
1. create table verification( id number, id2 number ) ; 2. create table verification2( id number, id2 number ) ;
これらのテーブルに
カラムidには 5000件づつ異なる値
カラムid2には 一意な値
を、それぞれ挿入する。
次に以下の6つのインデックスを作成する。
1. create index id_normal_idx on verification( id ) ; 作成時間 = 08.05 領域サイズ = 16.0MB 2. create index id_idx on verification2( id ) compress 1 ; 作成時間 = 07.59 領域サイズ = 13.0MB 3. create index id2_normal_idx on verification( id2 ) ; 作成時間 = 08.96 領域サイズ = 18.0MB 4. create index id2_idx on verification2( id2 ) compress 1 ; 作成時間 = 09.56 領域サイズ = 25.0MB 5. create index comp_normal_idx on verification( id, id2 ) ; 作成時間 = 09.82 領域サイズ = 22.0MB 6. create index comp_idx on verification( id, id2 ) compress 1 ; 作成時間 = 08.68 領域サイズ = 18.0MB
ちなみに6.が「夢イン」である。
＜作成時間について＞
インデックスを圧縮して作成した場合の作成時間は、重複キーの割合に若干依
存はするが主だった負荷は見受けられない。
逆に重複キーを保持する列が削除されることにより、作成時間は短縮されると
考えられる。
＜領域使用サイズについて＞
インデックスを圧縮して作成した場合の領域使用サイズは、インデックス1と2
で約3MBの領域削減になっている。インデックス5と6でも約4MBの領域削減にな
っている。重複キーがある程度存在する場合はインデックスを圧縮することに
よって、かなり領域を削減することが可能である。
しかし、注意が必要である。重複キーがまったく存在しないカラムid2のインデ
ックスに対して圧縮を実行すると、約7MBもの領域増加が発生してしまった。
なぜ、一意なカラムに対してインデックスの圧縮を行なうと領域使用サイズが
増加してしまうのであろうか？
＜インデックス圧縮時のTREE DUMP＞
branch: 0x40de0a 4251146 (0: nrow: 5, level: 2)
branch: 0x4132ad 4272813 (-1: nrow: 673, level: 1)
leaf: 0x40de0b 4251147 (-1: nrow: 346 rrow: 346) → ?
省略
＜インデックス圧縮時のLeaf Block DUMP＞
prefix row#0[8025] flag: -P---, lock: 0 → ?
col 0; len 4; (4): c3 64 40 4d
prc 1
prefix row#1[8009] flag: -P---, lock: 0
col 0; len 4; (4): c3 64 40 4e
prc 1
省略
row#0[8016] flag: -----, lock: 0 → ?
col 0; len 6; (6): 00 41 23 4a 00 6b
psno 0 → ?
row#1[8000] flag: -----, lock: 0
col 0; len 6; (6): 00 41 23 4a 00 6c
psno 1
省略
＜Normal インデックスのTREE DUMP＞
branch: 0x4143c2 4277186 (0: nrow: 4, level: 2)
branch: 0x41502c 4280364 (-1: nrow: 672, level: 1)
leaf: 0x4143c3 4277187 (-1: nrow: 485 rrow: 485) → ?
省略
＜Normal インデックスのLeaf Block DUMP＞
row#0[8019] flag: -----, lock: 0
col 0; len 3; (3): c2 05 57
col 1; len 6; (6): 00 41 1c 42 01 e5
row#1[8006] flag: -----, lock: 0
col 0; len 3; (3): c2 05 58
col 1; len 6; (6): 00 41 1c 42 01 e6
省略
DUMPの結果より、重複キーのまったく存在しないインデックスに圧縮を実行す
ると1Leaf Blockに収まるデータ量が減少している。( ?と?を比較 )
それに伴いインデックス領域使用サイズが増加しているのである。
( Leaf Block数の増加 )?のprefix row#で重複キーを管理しているのだが、
重複キーがまったく存在しない場合は?のrow#分?のprefix row#が存在するこ
とになる。prefix row#が多く存在する分、1Leaf Blockに収まるrow#を圧迫し
ているのである。
ちなみに重複キーと対応付けているものは、?のpsnoの数値と?のprefix row#
の数値である。
ゆえに、インデックスの圧縮作成はデータのカーディナリティ（重複度）を見
極めた上で作成することをお勧めします。
「夢イン」要素として
・検索時間
・作成時間
・使用領域サイズ
・DML処理のPerformance Up etc…
主に４つ存在するが、今回の検証で[ 作成時間 ][ 使用領域サイズ ]はインデ
ックスを圧縮することにより有効であると言える。
次回は、[ 検索時間 ]について検証を行なう。
次回もお楽しみに・・・つづく
以上 今日は、津軽弁の日らしい・・・ ビバ・ねぶた 茅ヶ崎にて