ASSMに関する検証 その３
＜ASSMに関する検証 その３＞
ペンネーム： サマー・リーフ
▼前回のおさらい
自動セグメント領域管理（ASSM）の表領域に作成したセグメント（テーブル）
のセグメントヘッダで管理する情報をダンプを覗いて確認してきました。
セグメントヘッダでは、ブロック情報をレベル分けして保持している事が、読
み取れましたね。
セグメントヘッダ ⇒レベル分けしたビットマップブロックの管理 Level III ⇒※前回の検証まででは、存在せず。 Level II ⇒Level 1の情報管理 Level 1 ⇒データ格納ブロックの空き情報管理
前回の予告で一呼吸おいて従来のFREELIST管理を見ていこうとしましたが、
改めて レベルってなんだろう？と思い直しもう少し追っかけます。
その１の回で自動セグメント領域管理（ASSM）は、以下のようにさらっとご紹
介しました。
「 Bツリー索引に”似た”構造でLevel分け（3Level）され空きブロックに対
し高速にアクセスが可能であることです。」
確かに Bツリー索引では、ルート⇒ブランチ⇒リーフと３つの”階層”に分けて
行データへのアクセスを速くするものです。したがって・・・・・、
ルート ⇒ セグメントヘッダ ブランチ ⇒ Level II ビットマップブロック リーフ ⇒ Level 1 ビットマップブロック
とイメージを持つと、セグメントヘッダ → Level II → Level 1 という
ようにアクセスして、空きブロックのブロックアドレスを特定する、と想像
できます。
では、まず自動セグメント領域管理（ASSM）のセグメントにデータを挿入して
データ管理状況を確認したいと思います。
暫く、ダンプ漬けにお付き合い下さい。
■環境
OS：WindowsXP
DB：Oracle10g EE Release 10.2.0.3
ITI1 スキーマ：自動セグメント領域管理（ASSM）表領域
ITI2 スキーマ：FREELIST管理 表領域
サンプルテーブル（上記スキーマに作成しています。）
テーブル名：SUMMER_LEAF
カラム名 型 ------------ ------------ COL_NUM NUMBER(5) COL_CHR CHAR(20) COL_VCHR VARCHAR2(20) COL_DAT DATE
※サンプルテーブルは、今回 カラム、型を変えて再作成しています。
本文内のブロックアドレスが、前回までの変わっているのでご注意！！
ITI1 スキーマの SUMMER_LEAF テーブルの情報を見ていきましょう。
セグメントヘッダブロックが、11番目のブロックである事が確認できます。
OWNER SEGMENT_NAME HEADER_FILE HEADER_BLOCK --------- -------------- ----------- ------------ ITI1 SUMMER_LEAF 7 11 ITI2 SUMMER_LEAF 8 9
1000000行追加して、再度セグメントヘッダブロックを覗いてみましょう。
alter system dump datafile 7 block 11;
Extent Map（Level 1 のビットマップブロックアドレス）、Auxillary Map
（エクステント単位の先頭ブロックアドレス）が、増えてます。
当たり前ですが・・・
↓ここから（セグメントヘッダブロックのダンプ内容）↓ ******************************************************************** ●各レベルの最終のブロックアドレス Last Level 1 BMB: 0x01c01b09 ←6921番目のブロック Last Level II BMB: 0x01c0000a ←10番目のブロック Last Level III BMB: 0x00000000 ←対象ブロックなし ●Level 1 のビットマップブロックアドレス Extent Map ----------------------------------------------------------------- 0x01c00009 length: 8 ← 9番目のブロック 0x01c00011 length: 8 ←17番目のブロック ～～ ●エクステント単位の先頭ブロックアドレス Auxillary Map -------------------------------------------------------- Extent 0 : L1 dba: 0x01c00009 Data dba: 0x01c0000c Extent 1 : L1 dba: 0x01c00009 Data dba: 0x01c00011 Extent 2 : L1 dba: 0x01c00019 Data dba: 0x01c0001a Extent 3 : L1 dba: 0x01c00019 Data dba: 0x01c00021 Extent 4 : L1 dba: 0x01c00029 Data dba: 0x01c0002a ～～ -------------------------------------------------------- ●⇒Level 2 のビットマップブロックアドレス Second Level Bitmap block DBAs -------------------------------------------------------- DBA 1: 0x01c0000a ******************************************************************** ↑ここまで（セグメントヘッダブロックのダンプ終わり）↑
サンプルテーブルに、1000000行入れたところでLevel II、IIIは増えませ
んでした・・・ かなりデータを投入しないと増えなさそうですね。
続けて Level II（SECOND LEVEL BITMAP BLOCK）の抜粋です。
↓ここから（Level 1 のビットマップブロックのダンプはじめ）↓ ******************************************************************** ●121番目のブロックアドレス（Level 1 のビットマップブロック） -------------------------------------------------------- DBA Ranges : -------------------------------------------------------- 0x01c00079 Length: 8 Offset: 0 0x01c00081 Length: 8 Offset: 8 0:Metadata 1:FULL 2:FULL 3:FULL ～～ 12:FULL 13:FULL 14:FULL 15:FULL ←※1 ●137番目のブロックアドレス（Level 1 のビットマップブロック） -------------------------------------------------------- DBA Ranges : -------------------------------------------------------- 0x01c00089 Length: 64 Offset: 0 0:Metadata 1:Metadata 2:FULL 3:FULL 4:FULL 5:FULL 6:FULL 7:FULL ～～ 56:FULL 57:FULL 58:FULL 59:FULL 60:FULL 61:FULL 62:FULL 63:FULL ←※2 ******************************************************************** ↑ここまで（Level 1 のビットマップブロックのダンプ終わり）↑
121番目のブロックアドレスである、Level 1 のビットマップブロックでは
16個のブロックの状態を管理しています。（※1）
ん？ 137番目のブロックアドレスである、Level 1 のビットマップブロック
を覗くと 64個のブロックの状態を管理しています。（※2）
Level1のビットマップブロックで管理されるブロック数が変わっていること
が判ります。これは、Level 1 のビットマップブロックで管理するエクステ
ントが拡張する際に、セグメントのサイズによって状態を管理するブロック
数が決まるようです。
セグメントをデフォルトで作成すると初期は、1つの Level 1 のビットマッ
プブロックが、16個のブロックを管理します。
データが格納されていき・・・
8K × 16 × 8 = 1024（1Mb） に到達すると、次のビットマップブロックが
管理するブロック数が変化します。
んん～ 次の閾値がありそうです・・・。
今週はここまで。
桜も一雨で、だいぶ散ってしまいました。
花見をしそびれ、週末は元気な桜を捜索です。 茅ヶ崎にて