ASSMに関する検証 その４
＜ASSMに関する検証 その４＞
ペンネーム： サマー・リーフ
※はじめに、本文内の “BMB” は、ビットマップブロックという用語を略して
いますので読み替えて下さい！
▼前回のおさらい
Level 1 の BMB が、どのようにブロック毎の空き情報を管理しているかをダ
ンプからみてきましたね。
管理するブロック数が、格納される行データ件数（セグメントサイズ）によっ
て変化する事が分かりました。
▼セグメントに行データが増えていくと、Level 1 の BMB は、どのようにブ
ロック情報が保持されるかをまとめます。
1. セグメント作成時
（ブロックサイズ 8K ＆ INITIAL EXTENT “8”ブロックの場合）
INITIAL EXTENTで指定されたブロック（デフォルト 8 ブロック）が確保さ
れ、3 ブロック（Level 1、Level II、セグメントヘッダー）は、管理ブロ
ックとなります。
従って Level 1 で管理する行データを格納可能なブロックは、 8 – 3 = 5
ブロックとなります。
2. 行データを格納（ 5ブロック分の行データを超えた時 ）
1.で確保された Level 1 の BMB は、16 ブロックの管理に書き換えられま
す。Level 1 で管理する行データを格納可能なブロックは、 16 – となります。
3. 更に、行データを格納（セグメントサイズが、1Mを超えた時）
新たに、確保される Level 1 の BMB は、64 ブロックを管理するようにな
ります。
4. そして更に、行データを格納（セグメントサイズが、64Mを超えた時）
新たに、確保される Level 1 の BMB は、256 ブロックを管理するようにな
ります。
5. 更に、更に、行データを格納（セグメントサイズが、1G を超えた時）
新たに、確保される Level 1 の BMB は、1024 ブロックを管理するように
なります。
※ここでは、ダンプを載せるのは割愛します。
セグメントサイズを 1G にする為には、＜ASSMに関する検証 その３＞で
記載したテストテーブルに、約1000万件の行データを格納してください。
行データが増え、セグメントサイズによって Level 1 の BMB で管理するブロ
ック数が変化する事をダンプを交えて確認してきました。
今回、検証した以上の行データ件数が増え大規模な環境になった場合、
Level II、Level III の BMB が複数生成され、Level 1 の BMB を紐付けられ
ることになります。
この BMB のレベル分けが、＜ASSMに関する検証 その１＞でご説明したよう
にセグメントのブロック情報を Bツリー索引に似た構造で保持して空きブロッ
クへのアクセスを高速にする事が特徴となります。
▼次に、＜ASSMに関する検証 その１＞でさらっと触れました Low、High HWM
について見てみましょう
まず HWMは、ダイレクトパスロードなど空きブロックを探さずに最終ブロック
から高速に行データを格納する為に必要でしたね。
（領域の有効活用より速さを求める時に使ったりします。）
自動セグメント領域管理（ASSM）では、以下のダンプにもあるように２つの
HWM（ Low、High HWM ）を保持しています。
↓ここから↓（セグメントヘッダーダンプ抜粋） ******************************************************************** Level 1 BMB for High HWM block: 0x01c00019 Level 1 BMB for Low HWM block: 0x01c00019 ******************************************************************** ↑ここまで↑
２つの HWM は、次のように定義できます。
High HWM より上のブロックは、データの格納が一度も実行されていない。
Low HWM より下のブロックは、データの格納が一度でも実行されている。
従来のFREELIST管理では、HWMを１つ保持してセグメントの最終ブロックの位
置を特定できました。
なぜ、２つの HWM を保持しているのでしょうか？
それは、High HWM ⇔ Low HWM のブロックアドレスに差が出来てしまう事があ
るからです。
なんのこっちゃ？？？
自動セグメント領域管理（ASSM）のアルゴリズムについて調べると、
“INSERT対象のブロックに対する競合を抑える為に、プロセスIDを使用したハ
ッシュ・アルゴリズムにより、INSERTの開始位置を分散させるという動作をす
る。”と記載されています。
確かに、Level 1 の BMB のダンプを参照するとランダムにブロック使用率が
更新されていました。
従って、必ず先頭のブロックから順番にブロックが、”FULL”になっていくわけ
ではありません。
↓ここから↓（Level 1 の BMB ダンプ抜粋）
********************************************************************
0:Metadata 1:Metadata 2:FULL 3:FULL
4:75-100% free 5:75-100% free 6:75-100% free 7:75-100% free
8:75-100% free 9:75-100% free 10:75-100% free 11:75-100% free
12:75-100% free 13:75-100% free 14:75-100% free 15:75-100% free
16:75-100% free 17:FULL 8:FULL 19:FULL
20:75-100% free 21:FULL 22:FULL 23:FULL
24:75-100% free 25:FULL 26:FULL 27:50-75% free
28:75-100% free 29:FULL 30:FULL 31:75-100% free
～～～～
********************************************************************
↑ここまで↑
Low HWM を上回るエクステントが、上記ダンプのようにどこがセグメントの最
終ブロックか特定できない状態に陥ります。
だから、High HWM を明示的に保持する事により、ダイレクトパスロードなど
の処理が High HWM 以降のブロックを対象に実行する事が出来ます。
今日は、ここまで。
次回は、Low、High HWM について、もっと掘り下げていこうと思います。
だいぶ暖かくなりましたね。
アウトドアシーズン到来です！ 茅ヶ崎にて