db2dartで学ぶDB2ストレージ・アーキテクチャ その３

今までの記事
db2dartで学ぶDB2ストレージ・アーキテクチャ　その１　表スペース内のエクステントについて
db2dartで学ぶDB2ストレージ・アーキテクチャ　その２　SMPの拡張タイミングについて


DB2の表スペースの内部構造について検証している今回のシリーズも、これで３回目の更新となります。
db2dartというツールを使って、表スペースの内部構造を調べていくという、やればやるほど誰得な企画になって参りました。
でもやりかけちゃったんで、とことん突き詰めて行きたいとおもいます。

１回目の記事では、表スペースの領域確保の仕組みについて、基本的な事柄を確認しました。
それから２回目の記事では、表スペース内の空きエクステント情報を管理するSMP（スペース・マップ・ページ）が拡張されるタイミングを検証しました。

３回目の今日は、オブジェクト毎に取られるEMP（エクステント・マップ・ページ）について確認していきます。


まずは軽く復習です。
表スペースを作成した直後、コンテナー内には４つのエクステントが確保されているんでした。

        エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ

そして、この表スペース内に表を作成すると、表のEMPと、データ・エクステントで2エクステントが最初に確保されます。

       エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ
                    3           12               15            表のEMP
                    4           16               19            表のデータエクステント

このEMPの中に、その表が確保したエクステントの位置情報が格納されています。


そして、最初のデータ・エクステントが一杯になると、あとは1エクステントずつデータ・エクステントを拡張していきます。

       エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし       コンテナー・タグ
                    0             0               3             表スペース・ヘッダー
                    1             4               7             SMP（スペース・マップ・ページ）
                    2             8               11             オブジェクト表データ
                    3           12               15            表のEMP
                    4           16               19            表のデータエクステント
                    5           20               23            表のデータエクステント
                       ・・・・

はい、ここで疑問です。
データ・エクステントが増加していくと、EMPに格納されている情報も増加します。
ということは、いつかEMPエクステントも溢れてしまうのでは？

ということでデータを増幅させて内部動作を確認してみました。
前回までと同じように、適当な表スペースを作成し、そこに表を作成し、ひたすらデータを増幅させます。


ある程度データ量が増えたら、db2dartをつかってEMPのダンプをとります。

db2dart <DB名> /DEMP /OI <オブジェクトID> /TSI <表スペースID>

そんで出てきた結果が以下のような感じになります。

    Object specific mapping info:
    -----------------------------
    DAT extent anchor: 12
    Traversing extent map for object type: 0
       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 12, # entries: 1000
       Page LSN = 0001 3B37 FE46
       Pool relative page #'s :
          16     20     24     28     32
          36     40     44     48     52
          56     60     64     68     72
       〜〜中略〜〜
        3956   3960   3964   3968   3972
        3976   3980   3984   3988   3992
        3996   4000   4004   4008   4012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 13, # entries: 1000
       Page LSN = 0001 3BF7 4AF2
       Pool relative page #'s :
        4016   4020   4024   4028   4032
        4036   4040   4044   4048   4052
      〜〜中略〜〜
        7976   7980   7984   7988   7992
        7996   8000   8004   8008   8012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 14, # entries: 1000
       Page LSN = 0001 3CB6 979E
       Pool relative page #'s :
        8016   8020   8024   8028   8032
        8036   8040   8044   8048   8052
      〜〜中略〜〜
       11976  11980  11984  11988  11992
       11996  12000  12004  12008  12012

       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 15, # entries: 32
       Page LSN = 0001 9963 2E43
       Pool relative page #'s :
       12016  28020  44024  60028  76032
       92036 108040 124044 140052 156056
      172060 188064 204068 220072 236076
      252080 268088 284092 300096 316100
      332104 348108 364112 380116 396124
      412128 428132 444136 460140 476144
      492148 508152
       Pool: 7, Object: 4 EMP page class: 64,
       EMP pool page: 12016, # entries: 1000
       Page LSN = 0001 3D75 E4E6
       Pool relative page #'s :
       12020  12024  12028  12032  12036
       12040  12044  12048  12052  12056
      〜〜後略〜〜

まずこの中の、

DAT extent anchor: 12

この部分が、表を作成した時に取られた初期EMPの先頭ページ番号を表しています。
今回はエクステント・サイズが4で、1つ目に作成した表なので12ページから4ページ分がEMPエクステントです。

そして、

EMP pool page: 12, # entries: 1000

この部分が、EMPページのページIDと、その中に何エクステント分の情報が入っているかという情報です。
今回はページID12番には、1000個のエクステント情報があると言っています。
そして、その後ろの

       Pool relative page #'s :
          16     20     24     28     32
          36     40     44     48     52
          56     60     64     68     72
       〜〜中略〜〜
        3956   3960   3964   3968   3972
        3976   3980   3984   3988   3992
        3996   4000   4004   4008   4012

が、そのEMPページで管理しているエクステントの、先頭ページ番号になります。
数えると確かに1000個ありました。
したがって、このダンプ結果の「EMP pool page: nn」のところを見ていけば、いくつEMPエクステントが取られたのかが確認できます。

さらにいうと、
「先頭EMPエクステント」の「最終ページ」
には、拡張されたEMPの位置が記録されています。
今回の先頭EMPエクステントは、ページIDが、12, 13, 14, 15 の4ページあります。
この中の最終ページ（==ページID5）の中に、拡張されたEMPがあるということです。

それが上記のダンプ結果の

       EMP pool page: 15, # entries: 32
       Page LSN = 0001 9963 2E43
       Pool relative page #'s :
       12016  28020  44024  60028  76032
       92036 108040 124044 140052 156056
      172060 188064 204068 220072 236076
      252080 268088 284092 300096 316100
      332104 348108 364112 380116 396124
      412128 428132 444136 460140 476144
      492148 508152

の部分になります。
ここをみれば、どのくらい拡張されたのか一目で分かります。


とうことで、表毎に取られるEMP（エクステント・マップ・ページ）の位置が確認できました。


それでは次に、ページ・サイズによる違いを見てみます。
当然ページ・サイズが大きくなれば、1つのEMPページで、より多くの情報が格納できるはず。
ということで、各ページ・サイズで表スペースを作成し、データを増幅してダンプをとります。

やることは上と同じなので割愛。
結果としてはこうなりました。

       ・表の作成時に、初期EMPエクステントが確保される
        ・初期EMPエクステントの最終ページには、拡張したEMPエクステントの位置が記録される
        ・ページサイズが4Kの場合、EMP1ページにつき、1000エクステントが管理できる
        ・ページサイズが8Kの場合、EMP1ページにつき、2026エクステントが管理できる
        ・ページサイズが16Kの場合、EMP1ページにつき、4074エクステントが管理できる
        ・ページサイズが32Kの場合、EMP1ページにつき、8170エクステントが管理できる

このEMPも、領域見積もりの結果に1割くらい多めにしておけば十分に吸収できるサイズでしょう。
ただ、厳密にシビアな見積りが必要な場合には、当然考慮する必要があります。

※この検証は9.1で実施しており、新しいバージョンでは動作が違う可能性があります。


では今回はここまで。
次回からはINDEXのエクステントのとり方を検証してみたいと思っています。