ロックに関する検証 その６
～ロックに関する検証 その６～
ペンネーム ちゃむ
前回は、ビットマップ・インデックスの構造の概要を説明した。
今回は、ビットマップ・インデックスの構造の詳細をさらに見ていこう。
前回使用したカーディナリティ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を取得して、ビットマップ・インデックス構
造の核心に迫ってみる。
以上 茅ヶ崎にて