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

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

今回は、キー圧縮インデックスのDML処理負荷の検証を行なう。
キー圧縮インデックスの[ DML処理 ]に変化は起こるのであろうか？

検証スタート！！！

検証目的：
前回作成した検証用テーブル( emp_200man )に、100万件のデータをInsertした
場合の[ DML処理 ]を各インデックスのType別処理時間を検証する。

検証用テーブル

create table emp_200man(  EMPNO NUMBER
                        , ENAME VARCHAR2(10)
                        , JOB VARCHAR2(9)
                        , MGR NUMBER(4)
                        , HIREDATE DATE
                        , SAL NUMBER(7,2)
                        , COMM NUMBER(7,2)
                        , DEPTNO NUMBER(2)
                       ) ;

データ件数は、200万件である。
このテーブルのカラムEMPNOは、一意な値である。

このテーブルに100万件のデータをInsertする。

SQL> insert into emp_200man select * from emp_100man ;

insertするデータのEMPNOは、一意な値である。

インデックスが存在しない場合のInsert処理時間は
Insert処理時間 = 2分02.04秒
である。

検証インデックスタイプ

1. create index normal_empno_idx on emp_200man( empno ) ;
    領域サイズ = 38.0MB( 200万件時 )
    領域サイズ = 80.0MB( 100万件 Insert後 )

  create index normal_ename_idx on emp_200man( ename ) ;
    領域サイズ = 38.0MB( 200万件時 )
    領域サイズ = 64.0MB( 100万件 Insert後 )

    合計領域サイズ = 76.0MB( 200万件時 )
    合計領域サイズ = 144.0MB( 100万件 Insert後 )

    Insert処理時間 = 14分31.08秒
2. create index normal2_idx on emp_200man( ename, empno ) ;
   領域サイズ = 52.0MB( 200万件時 )
   領域サイズ = 104.0MB( 100万件 Insert後 )

   Insert処理時間 = 10分11.06秒

3. create index comp_idx on emp_200man( ename, empno ) compress 1 ;
   領域サイズ = 38.0MB( 200万件時 )
   領域サイズ = 80.0MB( 100万件 Insert後 )

   Insert処理時間 = 9分41.07秒

上の結果より
検証インデックスタイプ1は、Oracle8i以前を想定している。このタイプと検証
インデックスタイプ2の結果を見ていただきたい。Index Skip Scanを実行でき
る環境であれば、領域サイズを約30% Insert処理時間も約30%削減することが可
能であった。また、Index Skip Scanを実行できると言うことは、複合インデッ
クスの第１キーのデータのカーディナリティーが低いと予想される。そこで、
キー圧縮を行なうことで( 検証インデックスタイプ1とタイプ3の比較 )、領域
サイズを約45% Insert処理時間を約33%削減することが可能であった。

＜今までの検証の総括＞
Oracle9iの環境をお持ちの方は、同一テーブルに対して複数のインデックス(
単一カラム )を持っている環境があれば、複合インデックス化を検討してみて
、Index Skip Scan検索処理でも既存のシステムに問題がなければ、複合インデ
ックスに作成し直すことをお勧めします。また、同時にキー圧縮を実行するこ
とにより、領域サイズ・DML処理時間を削減することが可能である。

Oracle8iの環境をお持ちの方は、既存のインデックスに第１キーのデータのカ
ーディナリティーが低い場合にキー圧縮を実行することで、インデックス検索
時間は変わらずに領域サイズ・DML処理を削減することが可能である。

次回は、各インデックスの種類別に検証を行なう。
とりあえず、Functionインデックスについて検証を行ないます。
検証してほしいインデックスの種類がございましたら、メールをいただければ
リクエストの多い順に検証を行なっていこうと思います。

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

以上
日本プロ野球が初めて米大リーグに勝った日らしい・・・松井がんばれ！！
茅ヶ崎にて

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