Home > db2 Archive

db2 Archive

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  • Comments (Close): -
  • TrackBack (Close): -

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

  • Posted by: Nakunaru
  • 2012-06-21 Thu 22:30:45
  • db2
今までの記事
db2dartで学ぶDB2ストレージ・アーキテクチャ その1 表スペース内のエクステントについて
db2dartで学ぶDB2ストレージ・アーキテクチャ その2 SMPの拡張タイミングについて


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

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

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


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

エクステント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のエクステントのとり方を検証してみたいと思っています。




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

  • Posted by: Nakunaru
  • 2012-06-06 Wed 23:56:27
  • db2
前回の記事はこちら

db2dartで学ぶDB2ストレージ・アーキテクチャ その1 表スペース内のエクステントについて
db2dartで学ぶDB2ストレージ・アーキテクチャ その2 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が新たにエクステントを確保しようとした際に、表スペースのどの位置が空きエクステントなのかを判別するために使用される情報を持っている。らしい。
表スペースの作成直後の状態(以下)では、空きエクステント情報のためのエクステントが1つ取られている。


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


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

やった内容は前回と同じで、
1.表スペース作成
2.表作成
3.ひたすらデータ増幅
4.頃合いを見て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の拡張タイミングを探って行きたいと思います。


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

それではまた次回まで。


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










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

  • Posted by: Nakunaru
  • 2012-06-03 Sun 17:15:44
  • db2
db2dartで学ぶDB2ストレージ・アーキテクチャ その1 表スペース内のエクステントについて
db2dartで学ぶDB2ストレージ・アーキテクチャ その2 SMPの拡張タイミングについて


最近、DB2絡みのお仕事が回ってきているので暇を見つけて勉強しております。
その中で、DB2がエクステントを確保する仕組みについて、いくつか気になる点があったので調べてみました。
そして、調べていく過程でdb2dartというツールの存在を知り、さらに色々と掘り下げてみたところ他社製品(というかORACLE)とは領域の扱い方が違う点などを発見できたので、少しずつまとめてみたいと思います。





とりあえず、基本的なエクステント管理の仕組みについて確認したあとで、内部のエクステント・マップを確認する方法などを紹介したいと思っています。
多分、1回のエントリーでは書ききれないので、複数回になる予定です。
ということで、今回は「その1」としました。

では、以下から本題です。



DB2の表スペース

Oracleなど表領域、テーブルスペースといった呼び方になりますが、DB2の文化圏では「表スペース」と呼ばれています。
基本的な概念はOracleと同じで、"表スペース"という論理構造に対し、"コンテナー"という物理構造を割り当て、データを格納するために使用するというものですね。
"コンテナー"という言い方なのは、ファイルだけでなく、デバイスやディレクトリも使用できるため、「データファイル」とは呼ばずに"コンテナー"になります。

tablespace.png







SMSとDMS

で、この表スペースは大きく2種類に分類ができて、「SMS表スペース」と「DMS表スペース」になります。
SMSは、コンテナーとしてディレクトリを使用し、領域管理はOSに投げっぱなしとなります。
DMSはDB2が領域管理を行い、コンテナーとしてデータファイルまたはデバイスが使用できます。
SMSの場合、この後書く予定の内部動作がかなり違っていますのでご了承ください。
今回はDMSを前提として調査を行なっています




ページ、エクステント、コンテナー

最初に基本的な用語を確認しておきます。
DB2も他の製品と同じように、I/Oの最小単位は「ページ」になります。
Oracleでは「データ・ブロック」と呼んでいるものですね。
ページ・サイズは表スペース毎に指定が可能で、それぞれ4K, 8K, 16K, 32K のいずれかになります。
デフォルトは4Kです。

そして、このページが連続する1つの固まりがエクステントになります。
エクステントは、表スペース内で、オブジェクトに領域が割り当てられる際の単位となり、デフォルトでは1エクステント32ページになります。

コンテナーは、表スペースに割り当てられたデータファイル、あるいはデバイスなどのことになります。

ということで、マニュアルでいうとこちら(http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Fc0004939.html&resultof=%22SMP%22%20%22smp%22%20)にひと通りの説明があります。




エクステント・マップの確認(db2dart)

この中に色々と気になる点があるのですが、とりあえず最初の疑問点として、エクステントの状態を確認できないのか?ということです。
Oracleでは、dba_segments や db_extents を検索することで、オブジェクト毎のエクステントの位置が確認できます。
db2でも、

db2 list tablespaces show detail


を叩くことで、表スペース内にエクステントがいくつ確保され、あと何ページの空きがあるのかということはわかりますが、表毎にエクステントが連続領域に取られているのか、断片化しているのかということは、このコマンドでは判別できません。
そこで、エクステントの状態を確認する方法がないかマニュアルを漁ってみると、db2dartというツールを見つけました。
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.cmd.doc%2Fdoc%2Fr0003477.html&resultof=%22db2dart%22%20

このツールは、コンテナーのファイルが壊れていないかを検査できる、ということなのですが、それ以外に表スペースの情報やページなどをダンプとして吐き出す機能を持っています。
マニュアルにはあまり詳しい説明がないので、試行錯誤しながらの調査でしたが、こいつを使ってエクステント・マップを確認することができました。

とりあえず使い方、構文です。

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


・DB別名:接続先のDBの名前を指定(ちょっと不正確な言い方ですがとりあえず)
・DEMP:表のEMP(エクステント・マップ・ページ)をダンプする
・/OI:表のオブジェクトIDを指定
・/TSI:表スペースのIDを指定
表のオブジェクトIDと表スペースIDは以下のSQLで予め確認しておくこと。

db2 "SELECT tabname, tableid, tbspaceid FROM syscat.tables WHERE tabname='XXXXXX'"




サンプルコード
-- 表スペース作成
db2 "create large tablespace spmtbs managed by database using(file 'spmtbs.dat' 10000) autoresize yes extentsize 4"

-- 表作成
db2 "create table big_tab1(a varchar(3000)) in spmtbs"

-- データ増幅
db2 "insert into big_tab1 values('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa')"
db2 "update big_tab1 set a = replace(a, 'a', 'aaaaaaaaaa')"
db2 "update big_tab1 set a = replace(a, 'a', 'aaaaaaaaaa')"
db2 "insert into big_tab1 select * from big_tab1" -- 2 rows
db2 "insert into big_tab1 select * from big_tab1" -- 4 rows
 ・・・

-- db2dart実行
db2 terminate
db2dart sample /DEMP /OI 4 /TSI 7

-- 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
-- 〜〜後略〜〜


解説

今回は1エクステント4ページの表スペースを作成しました。
表スペースを作成した時点で、内部では4つのエクステントが取られています。

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

コンテナー毎に、1エクステントのヘッダー領域が取られます。
でも、list tablespaces show detail やその他表スペース関連の情報を取得するコマンドでは、このコンテナー・タグの情報は出力されません。
問答無用で1エクステント削られます。
更に言うと、各エクステントには、エクステントIDが振られていますが、コンテナー・タグには割り振られません。そして、コンテナー内のページにもページIDが振られますが、コンテナー・タグの持つページにはIDがありません。
その後ろに来るのが表スペースのヘッダー情報。
その後ろが、SMP(スペース・マップ・ページ)で、これは表スペース内の空きエクステントの情報を持っています。(後ほどコレについても検証する予定)
オブジェクト表データというのは、この表スペース内に格納されているオブジェクトの情報を持つエクステント。
ということで、4エクステントが取られているわけです。

そんで、表スペースの中に表を1つ作成すると、表のヘッダーエクステントと、データ用のエクステントの2つが最初に取られます。
このヘッダーのエクステントが、EMP(エクステント・マップ・ページ)で、表のエクステント・マップが格納されているらしいです。


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



そして表のデータを増やしていき、最初に確保したデータエクステントが満タンになると、1エクステントずつ拡張していきます。

エクステント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_tab1のデータエクステント
・・・・


db2dart /DEMP の結果を見ていきます。

DAT extent anchor: 12


まず、ここが該当する表の最初に確保したEMPエクステントの開始ページ番号です。
今回は12番のページで始まるエクステントが、最初のEMPエクステントであることがわかります。


Pool: 7, Object: 4 EMP page class: 64,


Poolが表スペースのID、Object: 4 が表のID

EMP pool page: 12, # entries: 1000


12番のページから始まるEMPには、エクステント情報が1000個格納されているという意味。
ココらへんはまた後で詳しく検証する予定。

Pool relative page #'s :
16 20 24 28 32
36 40 44 48 52


ここに並んでいる数値が、この表のエクステントの開始ページ番号を表しています。
ということで、ここを見ればエクステントの配置がわかるということになります。


エクステント・マップを見たからどうだ、という話ではありませんが、これが確認できるとマニュアルに載っている様々な内部動作を、実際に確認し検証できます。
例えば、表スペース内の空きエクステント情報が入るSMPが溢れたら、どのように拡張されるのか。
今確認したEMPが溢れたらどうなるか。
ページ・サイズによって管理できるエクステント数は変わるのか。などなど…

そんなわけで、今後数回に渡りdb2dartを使って領域の使われ方を確認してきます。

あ、今回はdb2の9.1で検証しているのですが、バージョンによって内部構造は変わる可能性があります。
それと、9.1は既にサポート切れなので使用する際はご注意を。
それと、本ブログの内容は、あくまで個人的な見解ですのでご理解を。


Windows版のDB2 CLPをかっこ良く使いたい → Cygwin + CKW + CLP

  • Posted by: Nakunaru
  • 2011-02-06 Sun 18:20:30
  • db2
db2のCLPはCommand Line Processor の略で、オラクルでいうSQL*Plusの役割を果たすコマンドラインツールです。
UNIXだろうがLinuxだろうがWindowsだろうが、db2を使うならCLPでの作業ははずせません。

で、このCLP、Windowsなら当然DOSのコマンドプロンプトで使うわけですが、SQL*Plusとはちょっと使い勝手が違います。
Oracleでは、管理作業はほぼすべてSQL*Plusから行いますよね。例えばインスタンスの起動も、SQL*Plusからstartupコマンドですし。
でもdb2は、CLPから実行する管理コマンドと、OSコマンドとして実行する管理コマンドが混在しています。
例えばインスタンス起動は、OS上でdb2start コマンドを叩きます。
つまり、いったんCLPから抜けて実行しなければならないわけです。

また、Oracleで初期化パラメータを確認するには、show parameterコマンドがお手軽ですが、これはキーワードでの絞り込みが簡単ですよね?

show parameter db_


などとすると、「db_」が含まれるパラメータだけが表示されると。
でもdb2では、CLPを起動した状態で、

get dbm cfg


というコマンドを叩くと、全パラメータが出力されます。
絞り込みの機能はありません。
で、これでは不便なので、

db2 "get dbm cfg" | grep SVR


などとして、CLPを非対話モードで実行し、その結果をgrepするとかそんな使い方になります。
前置きが長くなりましたけど、要するにCLPは非対話モードで、OSコマンドの一部として使うことが多いということを言いたかったわけです。


そんで、そうなると気になるがコマンドラインそのものの使い勝手。
例えばファイル名のTABキーによる補完とか、DIRの代わりにlsを使いたいとか、ログファイルをtail -f で監視したいとかとかとか。
Windowsのコマンドプロンプトを便利に使うツールがないか、探してみると以下がヒットしました。

http://www.nyaos.org/
http://www.winunix.dreamhosters.com/winunix/shell.htm

そして、このnyacusというワードで検索すると、CKWというツールもヒットしてきます。
http://lucy.moe-nifty.com/blog/2009/10/windowslinux-88.html

ふむふむ。なるほど。
CKWはコマンドプロンプトで、ウィンドウの透過などの設定ができる。
nyacusはシェルの強化ができる。
そんで、ckwでは起動シェルが選択できるから、nyacusで実行すればよい。
とかそんな内容っぽい。
これはなかなかに面白い、ということで色々カスタマイズをしてみたのですが、CLPの使用で問題がありました。


WindowsのDOSプロンプトで、CLPを起動しようとすると、「DB21061E コマンド行環境は初期化されていません。」と表示されて起動できません。
これは、Windows版のCLPは環境変数だったりクライアント情報だったりを読み込まないと起動できないっぽいのですが、生のDOSプロンプトではそれらが読めてないからだということらしい。
こちらのブログで、いろいろ試しているようですので気になる方はどうぞ。
http://plaza.rakuten.co.jp/u703331/diary/200705160001/

で、私もなんとかCKWでclpが使えないか色々やってみた結果、使えるようにはなりましたが、dbへ接続しても1秒程で切断されてしまう現象は解決できませんでした。

そんなわけで方向転換です。
シェルの拡張は、Cygwinで解決しようということで、CygwinからCLPが使えないか調査。
で、調査を開始してすぐ見つかったのがやっぱりこのブログ。
いつもいつも助かります。
http://db2.jugem.cc/?eid=865

ここでは.bashrcとしていますが、まぁ読み込まれるファイルならどこでもいいでしょう。
環境に合わせて、以下を追記すればオッケーなようです。

export DB2CLP=**$$**
export DB2PATH=C:\\SQLLIB



上記設定で、CygwinからCLPが使えるようになりました。



で、ここではたと思いついたわけです。
CKWの「Ckw*exec」パラメータに、Cygwin.batを指定したら使えるんじゃね?と。

で、やってみたらこれがビンゴ。
透過ウィンドウでCygwinが動いて、db2も使えちゃいました。
そんなわけで、現在のcfgファイルは以下の通り。


!
! ckw setting
!
Ckw*foreground: #00ff00
Ckw*background: #000000
Ckw*cursorColor: green
Ckw*cursorImeColor: red
Ckw*title: ckw[Cygwin]
Ckw*exec: D:\Cygwin\Cygwin.bat ! ## ←これをいれるだけ ##
Ckw*chdir: d:\
Ckw*scrollHide: no
Ckw*scrollRight: yes
Ckw*internalBorder: 1
Ckw*lineSpace: 0
Ckw*topmost: no
Ckw*transp: 180
Ckw*transpColor: #000000
Ckw*font: MS Gothic
Ckw*fontSize: 14
Ckw*geometry: 110x35
Ckw*saveLines: 800
Ckw*color0: #333333
Ckw*color1: #4682B4
Ckw*color2: #90EE90
Ckw*color3: #00BFFF
Ckw*color4: #FF00FF
Ckw*color5: #FF8080
Ckw*color6: #FFFF00
Ckw*color7: #CCCCCC
Ckw*color8: #333333
Ckw*color9: #4682B4
Ckw*color10: #90EE90
Ckw*color11: #00BFFF
Ckw*color12: #FF00FF
Ckw*color13: #FF8080
Ckw*color14: #FFFF00
Ckw*color15: #CCCCCC



はい、というわけで、現在はCygwin + CKW + CLPという環境で快適に作業しております。

今回の件で、改めて参考URLをあさっていたら、あたらしいバージョンを作っている方を発見しました。
http://craftwave.blogspot.com/2010/05/ckw-2-copyall.html
これ、メニューのなかに「CopyALL」というメニューを追加してくれているんですが、地味に便利です。






[関連]Windowsのコマンドプロンプトを便利にしてくれるCKW
http://hitai.blog72.fc2.com/blog-entry-77.html

DB2のSELECT文でNULLを選択したい

  • Posted by: Nakunaru
  • 2011-02-06 Sun 17:34:11
  • db2
表題の通り。
Oracleなんかでは普通にできる、以下のようなSELECT文を実行したわけです。


SELECT empno, null, ename from employees;



で、実行すると

SQL0206N "NULL" is not valid in the context where it is used. SQLSTATE=42703


と表示されてエラーに。
今回はNULL除外の条件などがWHERE句にごちゃごちゃ入っていたので、どこで構文がちがったのかと小一時間ハマっておりました。
そんで、Google先生に聞いてみるとやっぱり以下のブログがヒット。
http://db2.jugem.cc/?eid=940
いやー、まいど助かります。

ということで、結論としてはデータ型が不定なままでNULLはイカンでしょうと。
CASTで適当なデータ型を指定すればオッケーとのことでした。

SELECT empno, CAST(NULL AS int), ename from employee







Index of all entries

Home > db2 Archive

タグクラウド
Categories
Monthly
Recent Entries
Recent Comments
Recent Trackbacks
Appendix

Nakunaru

    Author:Nakunaru

    データベース(ORACLEとかSQL ServerとかDB2とかMySQLとか)とか技術者教育とかプログラムとか。
    気になる技術を少しずつ勉強していきます。


Return to page top

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。