ロックに関する検証 その6

投稿日: 2001年6月06日

~ロックに関する検証 その6~
ペンネーム ちゃむ

前回は、ビットマップ・インデックスの構造の概要を説明した。
今回は、ビットマップ・インデックスの構造の詳細をさらに見ていこう。

前回使用したカーディナリティ4のビットマップ・インデックスを使用し、詳細
な構造を見ていこう。詳細な構造を知るには、やはりお馴染みのダンプが必要
である。今回は、Oracle8以降のダンプの取得方法で行なうが、Oracle7以前の
方法を知りたければ、バックナンバーの「続・インデックスに関する検証」を
参照いただきたい。

********************** カーディナリティ4の場合 ***********************

SQL> CREATE BITMAP INDEX BITMAP_4 ON T10MAN_COPY_4(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BITMAP_4' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BITMAP_4                    90        89

さらに細かく、EXTENTS=89個のすべてのエクステントのBLOCK_IDを見ていこう。
このBLOCK_IDが、後程行うダンプの解析で役に立つ。また、89行検索されてい
るが、当然これは、EXTENTS=89個と一致し、エクステントが89個あることを意
味する。また、セグメントヘッダーを含んでいるエクステント(BLOCK_ID=24065)
以外はすべてBLOCKS=1なので、1ブロックのエクステントであることを意味する。
ちなみに、この検証では、セグメントヘッダーとBranchブロックが同じエクス
テント内に1ブロックずつ格納された(インデックスの構造は通常、「ルート」、
「ブランチ」、「リーフ」といった具合に3階層構造となっている(詳しくは、
バックナンバー「インデックスに関する検証」を参照)。しかし、この検証で
用いたインデックスの構造は、比較的小さいため、「ルート」を除いた、
「ブランチ」、「リーフ」の2階層で構成されている。したがって、セグメント
の先頭に必ず存在するセグメント・ヘッダーと、インデックス構造の先頭に位
置する「ルート」(ここではブランチ)が、ここでは同じエクステント内に格
納されていることを表している)。

SQL> SELECT FILE_ID,BLOCK_ID,BLOCKS FROM DBA_EXTENTS
     WHERE SEGMENT_NAME = 'BITMAP_4' ORDER BY BLOCK_ID ;

FILE_ID  BLOCK_ID    BLOCKS
--------- --------- ---------
        4     18333         1
        4     22960         1
        4     23025         1
        4     23043         1
        4     23075         1
        4     23133         1
        4     23146         1
        :       :           :
        :       :           :
        4     24065         2 ← セグメントヘッダーが含まれている
        :       :           :
        :       :           :
        4     83004         1
        4     83036         1
        4     83039         1
        4     83055         1
        4     83070         1
        4     83132         1
        4     83164         1
89行が選択されました。

次に、ビットマップ・インデックスBITMAP_4のTREE DUMPを取得する。DUMPを取
得するためには、OBJECT_IDが必要となる。

SQL> SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = 'BITMAP_4' ;

OBJECT_ID
---------
     5719

OBJECT_IDを指定してTREE DUMPを取得(初期化パラメータのUSER_DUMP_DESTに
設定されているディレクトリに出力される)

SQL> ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME TREEDUMP LEVEL 5719' ;

以前、ビットマップ・インデックスは、B-Treeインデックスの構造の中に格納
されていると説明したが、TREE DUMPを取得できるところからも明らかであろう。
以下のTREE DUMPを見ると、TREEの高さが2階層のインデックスであるというこ
とがわかる。前述してあるが、root-branch-leafという3階層構造ではなく、イ
ンデックスのサイズが小さいために、rootのないbranch-leafという構造になっ
ている。

また、TREE DUMPの中のnrow、rrow の違いは、バックナンバー
「続・インデックスに関する検証 その3」を参照していただきたいが、今回は、
nrowだけに着目して説明する。nrowは、インデックスのリーフに格納されてい
る行数と考えればよい。B-Treeインデックスであれば、この行数は、カラム長
にもよるが、20から50行くらいあるのが普通である。しかし、ビットマップ・
インデックスでは、殆どが1行で、多くても2行である。実は、ここにビットマップ・
インデックスのロックの問題が潜んでいるのであるが...。
branch blockに関しては、88行存在しているが、それは、リーフ・ブロックの
DBA(DATA BLOCK ADDRESS)とカラム値を含んでいるものであり、役割としては
B-Treeインデックスのbranchと殆ど同じである(若干構造は異なるが...)。

*************** ビットマップ・インデックスのTREE DUMP ****************

branch: 0x1005e02 16801282 (0: nrow: 88, level: 1)  ← branch block
   leaf: 0x1005da6 16801190 (-1: nrow: 1 rrow: 1)   ← reaf   block
   leaf: 0x1005f11 16801553 (0: nrow: 1 rrow: 1)
            :          :          :
            :          :          :
            :          :          :
   leaf: 0x10143ec 16860140 (16: nrow: 1 rrow: 1)
   leaf: 0x1005b34 16800564 (17: nrow: 1 rrow: 1)
   leaf: 0x1011795 16848789 (18: nrow: 1 rrow: 1)
   leaf: 0x1011867 16848999 (19: nrow: 1 rrow: 1)
   leaf: 0x10141b3 16859571 (20: nrow: 2 rrow: 2)
   leaf: 0x1014221 16859681 (21: nrow: 1 rrow: 1)
   leaf: 0x101443c 16860220 (22: nrow: 1 rrow: 1)
            :          :          :
            :          :          :
            :          :          :
   leaf: 0x101429e 16859806 (81: nrow: 1 rrow: 1)
   leaf: 0x101445c 16860252 (82: nrow: 1 rrow: 1)
   leaf: 0x1005fd9 16801753 (83: nrow: 1 rrow: 1)
   leaf: 0x100479d 16795549 (84: nrow: 1 rrow: 1)
   leaf: 0x10059b0 16800176 (85: nrow: 1 rrow: 1)
   leaf: 0x1005a6a 16800362 (86: nrow: 2 rrow: 2)

**********************************************************************

次回はさらに、詳細なBLOCK DUMPを取得して、ビットマップ・インデックス構
造の核心に迫ってみる。

以上 茅ヶ崎にて