新インデックスの検証　その８

＜新インデックスの検証　その８＞　ペンネーム　モンキーターン

今回は、bitmap join インデックス( Oracle9iから )の検証を行なう。

bitmap join インデックスとは、複数の表の結合に対するビットマップ索引で
ある。事前に結合結果を格納することが可能となる。
検索時間は、大幅にPerformance Upされそうであるが、その他の処理について
はどうであろうか？
それでは、bitmap join インデックスを[ 作成時間 ][ 領域サイズ ][ 検索時間 ]
[ DML処理時間 ]について検証を行なう。

検証スタート！！！

検索テーブル( emp_100man と dept_100man ）を用意する。
これは、empテーブルとdeptテーブルをそれぞれ100万件にしたものである。
emp_100manテーブルのempnoカラムは一意なデータを挿入。
dept_100manテーブルには、idカラムを追加。idカラムには、emp_100manテー
ブルのempnoカラムと同じ一意なデータが挿入されている。

＜bitmap join インデックスの作成＞

SQL>  create bitmap index bit_join_idx on emp_100man(dept_100man.id)
  2   from emp_100man, dept_100man
  3   where emp_100man.empno = dept_100man.id ;

行2でエラーが発生しました。:
ORA-25954: ディメンションのプライマリ・キーまたは一意の制約が欠落しています

えーー！！エラー発生？

bitmap join インデックスには、結合結果の格納するので以下の制限事項があ
ります。( Oracle Reference抜粋 )
・パラレルDML は現在ファクト表のみサポートされます。使用しているディメ
ンション表のうちの1 つのパラレルDML で、索引は使用禁止のマークが付け
られます。
・ビットマップ・ジョイン・インデックスを使用する場合、異なるトランザク
ションで同時に更新できる表は1 つのみです。
・結合に2 回同じ表は使用できません。
・索引構成表や一時表には、ビットマップ・ジョイン・インデックスを作成
できません。
・索引の列は、すべてディメンション表の列である必要があります。
・ディメンション表の結合列は、主キー列であるか、一意制約を持つ必要があ
ります。
・ディメンション表に複合主キーがある場合、主キーの各列が結合の一部であ
る必要があります。

なるほど。今回は、制限事項の下から２番目に引っかかっているみたいだ。
なので、

SQL> alter table dept_100man add unique(id) ;

表が変更されました。

SQL> create bitmap index bit_join_idx on emp_100man(dept_100man.id)
  2  from emp_100man, dept_100man
  3  where emp_100man.empno = dept_100man.id ;
索引が作成されました。

今度は、bitmap join インデックスの作成成功！！
[ 作成時間 = 1分29.06秒 ]
[ 領域使用サイズ = 28.0MB ]

Normal bitmap インデックスの場合
[ 作成時間 = 57.07秒 ]
[ 領域使用サイズ = 28.0MB ]

＜ bitmap join インデックスを使用した場合の検索＞

SQL> select /*+ index_combine(emp_100man bit_join_idx) */ count(*)
       from emp_100man, dept_100man
       where emp_100man.empno  = dept_100man.id ;

実行計画
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (AGGREGATE)
   2    1     BITMAP CONVERSION (COUNT)
   3    2       BITMAP INDEX (FULL SCAN) OF 'BIT_JOIN_IDX'

[ 検索時間 = 2.08秒 ]

SQL> select count(*)
from emp_100man, dept_100man
where emp_100man.empno = dep_100man.id ;

実行計画
———————————————————-
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 HASH JOIN
3 2 TABLE ACCESS (FULL) OF ‘EMP_100MAN’
4 2 INDEX (FAST FULL SCAN) OF ‘SYS_C003407’
[/sql]
[ 検索時間 = 52.07秒 ]

以上の結果より
bitmapでデータを管理するので、領域サイズの問題はないと考えられる。また、
事前に結合結果を管理するマテリアライズド・ビューよりも効率よくデータを
格納することが可能である。
検索時間に関しては、約52秒が約2秒に削減されている。結合結果のインデック
スに対してのみ検索を実行するだけでよいので、大幅なPerformance Upが期待
できる。
作成時間は、結合処理が入るので大幅に遅くなると思っていたが、思っていた
よりも高速で作成することが可能である。
果たして、DML処理は・・・

今回は、ここまで。
次回は、bitmap join indexの[ DML処理時間 ]について検証を行なう。

次回もお楽しみに・・・つづく

以上雨しとしと茅ヶ崎にて

新インデックスの検証 その８