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

前回の記事はこちら

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


前回はDB2の表スペースの基本的な概念を確認した上で、コンテナー上にエクステントが取られていく様子を確認しました。

今回は、表スペースのいわばヘッダー領域として取られる"コンテナー・タグ"、”表スペース・ヘッダー”、"SMP（スペース・マップ・ページ）"、"オブジェクト表データ"のうち、SMPの挙動について確認します。


SMP（スペース・マップ・ページ）
参考：http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Fc0008085.html

SMPは、DB2が新たにエクステントを確保しようとした際に、表スペースのどの位置が空きエクステントなのかを判別するために使用される情報を持っている。らしい。
表スペースの作成直後の状態（以下）では、空きエクステント情報のためのエクステントが１つ取られている。

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

だとすると、エクステントの数が増えていくことでSMP内の情報も多くなり、やがてあふれることになるはず。
ということで、何エクステントごとにSMPエクステントが拡張されるのか試してみました。

やった内容は前回と同じで、
１．表スペース作成
２．表作成
３．ひたすらデータ増幅
４．頃合いを見てdb2dart
という流れです。

SMPの情報は以下のオプションで取得できます。

db2dart <DB名> /DTSF

DはdumpのDかな？
TSがTableSpaceで、Fはなんだろう。
Formatかな。Fileかな。
まぁとにかくデータを増幅して、ひたすらエクステントを拡張しながら何か変化がでるまでdb2dartのレポートを見ていきます。



表スペースの作成直後

まず、表スペースを作成した直後のレポートをみると、こんな部分が見つかりました。

SMP page for first free extent: 4                            -- 初期SMPの先頭ページ番号
SMP page for last allocated tablespace extent.  7            -- 直近で獲得されたSMPの最後のページ番号
SMP extent number of the last initialized SMP extent:  0     -- SMPエクステントが拡張された回数

今回はextentsizeを4ページで作成しているため、上で書いたようにページ番号4からSMPがあるはずです。
そして、4番から始まったSMPエクステントの最終ページ番号は7になるので、上記レポートの内容と一致します。
更に、「SMP extent number of the last initialized SMP extent: 0」の通り、まだSMPエクステントは、初期にとられた1つしかないということも確認できます。


データ増幅後

では、ひたすらデータを追加していき、db2dartのレポートに変化がでるまで続けます。
あまりこまめに繰り返してもかったるいので、データを追加するスクリプトを流しつつ、15分おきくらいに様子をみていたところ、レポートに次のような出力がでてきました。

SMP page for first free extent: 4
SMP page for last allocated tablespace extent.  512003
SMP extent number of the last initialized SMP extent:  4

「SMP extent number of the last initialized SMP extent: 4」は、SMPエクステントが4回拡張されたということになるはず。
うっかりデータ増幅を放置しすぎて、いつの間にか拡張を繰り返していたようです。
途中のSMPエクステントがどこなのか、今の時点ではわかりませんが、下記のような状態になっているということです。

             ページサイズ：4k、エクステント・サイズ：4ページの場合
            エクステントID  開始ページ番号  終了ページ番号  役割
            ------------------------------------------------------
                    なし        なし            なし        コンテナー・タグ
                    0           0               3           表スペース・ヘッダー
                    1           4               7           SMP（スペース・マップ・ページ）
                    2           8               11          オブジェクト表データ
                    3           12              15          big_tab1のEMP
                    4           16              19          big_tab1のデータエクステント
                    5           20              23          big_tab2のデータエクステント
                        〜〜中略〜〜
                    不明        不明            不明        2つ目のSPMエクステント
                        〜〜中略〜〜
                    不明        不明            不明        3つ目のSPMエクステント
                        〜〜中略〜〜
                    不明        不明            不明        4つ目のSPMエクステント
                        〜〜中略〜〜
                    128000      512000          512003      5つ目のSPMエクステント
                        〜〜後略〜〜
            ------------------------------------------------------

この/DTSFオプションにより、最後にあるSMPの位置は確認できるが、途中にあるSMPについては確認できません。
これを判別するために、次のようなことを考えました。
今、表スペースに格納されているオブジェクトは表が1つのみ。
ということは、表のエクステント・マップを出力すれば、それ以外のエクステントがSMPである可能性が高いのでは？

ということで、さっそく表のエクステント・マップを出力します。
表のエクステント・マップの出力方法は前回の記事で書いた通り。

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
                        〜〜中略〜〜
                     520380 520384 520388 520392 520396
                     520400 520404 520408 520412 520416
                     520420 520424

エクステントが多すぎてページ番号が偉い桁数になってますが、とりあえずは出ました。
で、目視で抜けたエクステントを探すのはしんどいので、抜けを探すスクリプトで可視化しました。

               -- *** EMP and Other Extents ***
                -- ExtentId:3 EMP
                -- ExtentId:3004 EMP
                -- ExtentId:7005 EMP
                -- ExtentId:11006 EMP
                -- ExtentId:15007 EMP
                -- ExtentId:19008 EMP
                -- ExtentId:23009 EMP
                -- ExtentId:27010 EMP
                -- ExtentId:31011 EMP
                -- Extent Id:32000 OTHER
                -- ExtentId:35013 EMP
                -- ExtentId:39014 EMP
                -- ExtentId:43015 EMP
                -- ExtentId:47016 EMP
                -- ExtentId:51017 EMP
                -- ExtentId:55018 EMP
                -- ExtentId:59019 EMP
                -- ExtentId:63020 EMP
                -- Extent Id:64000 OTHER
                -- ExtentId:67022 EMP
                -- ExtentId:71023 EMP
                -- ExtentId:75024 EMP
                -- ExtentId:79025 EMP
                -- ExtentId:83026 EMP
                -- ExtentId:87027 EMP
                -- ExtentId:91028 EMP
                -- ExtentId:95029 EMP
                -- Extent Id:96000 OTHER
                -- ExtentId:99031 EMP
                -- ExtentId:103032 EMP
                -- ExtentId:107033 EMP
                -- ExtentId:111034 EMP
                -- ExtentId:115035 EMP
                -- ExtentId:119036 EMP
                -- ExtentId:123037 EMP
                -- ExtentId:127038 EMP
                -- Extent Id:128000 OTHER

ここで「EMP」と表示しているのは、表のエクステント・マップ情報をもつEMPエクステントのエクステント番号。
「OTHER」としているのが、表のデータおよびEMPエクステント以外のエクステントです。
つまり結果として、32000, 64000, 9600, 12800 の4つが表以外のエクステントであることが分かる。



SMPエクステントの拡張タイミング

上記の結果から、まだ確証は無いが、おそらく32000エクステント毎にSMPが拡張していることが予測できた。
この32000という数値の根拠を調査するために、SPMエクステントのページ・ダンプを出力して中身を見てみることにする。
ページ・ダンプの取得は/DPオプションを使用する。

db2dart <DB名> /DP /TSI <表スペースID> /PS <開始ページ番号> /NP <ページ数>

ページ番号4から4ページ分（初期SMPエクステント）のページ・ダンプを確認すると、各ページ毎に、0050の行の17ビットから、0FF0の行の16ビットまでほぼ全てに1が立っている。

0050  *00000000 00000000 11111111 11111111
0FF0  *11111111 11111111 00000000 00000000

それに対し、512000番から4ページ分（最終SPMエクステント）のページ・ダンプでは、0050の行の17ビット目から1が立っているのは変わらないが、0470の行から0になっている。

0470  *11111111 00001011 00000000 00000000*     *................*

このことから、0050の17ビット移行、0FF0の16ビットまでが、エクステントの空きを表しているのではないかと仮説を立ててみる。

この仮説を確認するために、上記ビットの数を確認すると、0050の17ビット〜0FF0の16までで、8000ビットある。
現在のエクステントサイズは1エクステント4ページなので、1つのSPMエクステントで、8000*4=32000エクステントが管理できることになる。
この数値は、上で確認したSPMエクステントの拡張タイミングと一致する。
したがって、ページサイズが4Kの場合、8000*エクステントサイズ（ページ数）毎に、SPMエクステントが拡張されることがわかった。

で、そうなると、当然ページサイズが異なれば、1ページで管理できるビット数も変わるはず。
ページサイズが8K,16K32Kの場合ではどうなるのか、同様の手順でダンプを取りながら確認した。
作業の流れは同じなので、途中経過は割愛するけど、結果として以下のタイミングでSMPエクステントが拡張されることを確認できた。


ページサイズによるSMPエクステントの拡張タイミング

SMPエクステントの拡張タイミングは以下の通り。

                ページサイズ        管理エクステント数
                -----------------------------------------------
                     4K              8000 * エクステントサイズ
                     8K             16208 * エクステントサイズ
                    16K             32592 * エクステントサイズ
                    32K             65360 * エクステントサイズ

そんなわけで、表スペースには、表や索引のエクステント以外のものがちょくちょく取られることが確認できました。
領域見積もりの際には、一応考慮に入れておくべきかなぁとは思いますが、全体のサイズからすると誤差みたいなもんなんで、通常良く言われる「見積もり結果より1割程度大きめにとっとこうね」で十分だと思います。
それよりも、今回の検証の中で表のデータエクステント以外を洗い出してみたところ、表のEMP（エクステント・マップ・ページ）が結構な頻度で拡張していることがわかりました。
多分こっちのほうが見積もりに与える影響が大きそうなので、次回はEMPの拡張タイミングを探って行きたいと思います。


いやー、それにしてもプロプラな製品のダンプを見ながら解析するのって楽しいですね。
とくにページ・ダンプは色々みれて面白いです。
後で別エントリーにする予定ですが、例えば索引のエクステントって、複数索引で同じエクステントに同居してたりとか、ルート・ページがどうやら共有されているっぽいとか。
ちょっとまだ調査中ですけど、色々と見えてくるものがあってしばらくはこれで遊べそうです。

それではまた次回まで。


※このエントリーは個人の見解であり、内容の正確性の保証はありません。
間違いなど見つけられた場合はコメントなど頂けると助かります。