ASSMに関する検証 その4

<ASSMに関する検証 その4>
ペンネーム: サマー・リーフ

※はじめに、本文内の “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に関する検証 その3>で
記載したテストテーブルに、約1000万件の行データを格納してください。

行データが増え、セグメントサイズによって Level 1 の BMB で管理するブロ
ック数が変化する事をダンプを交えて確認してきました。

今回、検証した以上の行データ件数が増え大規模な環境になった場合、
Level II、Level III の BMB が複数生成され、Level 1 の BMB を紐付けられ
ることになります。

この BMB のレベル分けが、<ASSMに関する検証 その1>でご説明したよう
にセグメントのブロック情報を Bツリー索引に似た構造で保持して空きブロッ
クへのアクセスを高速にする事が特徴となります。

▼次に、<ASSMに関する検証 その1>でさらっと触れました Low、High HWM
について見てみましょう

まず HWMは、ダイレクトパスロードなど空きブロックを探さずに最終ブロック
から高速に行データを格納する為に必要でしたね。
(領域の有効活用より速さを求める時に使ったりします。)

自動セグメント領域管理(ASSM)では、以下のダンプにもあるように2つの
HWM( Low、High HWM )を保持しています。

  ↓ここから↓(セグメントヘッダーダンプ抜粋)
  ********************************************************************
  Level 1 BMB for High HWM block: 0x01c00019
  Level 1 BMB for Low  HWM block: 0x01c00019
  ********************************************************************
  ↑ここまで↑

2つの HWM は、次のように定義できます。

High HWM より上のブロックは、データの格納が一度も実行されていない。
Low HWM より下のブロックは、データの格納が一度でも実行されている。

従来のFREELIST管理では、HWMを1つ保持してセグメントの最終ブロックの位
置を特定できました。

なぜ、2つの 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 について、もっと掘り下げていこうと思います。

だいぶ暖かくなりましたね。
アウトドアシーズン到来です! 茅ヶ崎にて