ASSMに関する検証 その２
＜ASSMに関する検証 その２＞
ペンネーム： サマー・リーフ
▼前回のおさらい
セグメントの空き領域を管理する方法は、２種類ありました。
1.FREELIST管理
2.自動セグメント領域管理（ASSM）
従来のFREELIST管理と比較し自動セグメント領域管理は、内部的にどのように
なっているかをセグメントヘッダダンプを覗いて違いをみました
自動セグメント領域管理でのセグメントヘッダダンプでは、Level分けされた
ビットマップや High, Low HWM などがありましたね。
まずは、Level分けされたビットマップについて掘り下げていってみましょう。
High, Low HWM に関しては、別の回で取り上げます。
■環境
OS：WindowsXP
DB：Oracle10g EE Release 10.2.0.3
■Level分けされたビットマップ
前回、ITI1 スキーマ、ITI2 スキーマ所有のテーブルはセグメント領域管理
の違う表領域に作成していていることをご紹介しました。
前者は、自動セグメント領域管理（ASSM）表領域、後者が FREELIST管理の
表領域でしたね。
それでは自動セグメント領域管理（ASSM）の管理構造を見る為に、ITI1 ス
キーマの SUMMER_LEAF テーブルの情報を見ていきましょう。
セグメントヘッダブロックが、27番目のブロックである事が確認できます。
OWNER SEGMENT_NAME HEADER_FILE HEADER_BLOCK -------- ---------------------- ----------- ------------ ITI1 SUMMER_LEAF 7 27 ITI2 SUMMER_LEAF 8 25
次に、再度 27番目のブロックのダンプの抜粋を見てみましょう。
↓ここから↓
********************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 8
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c00021 ext#: 0 blk#: 8 ext size: 8
～～
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01c0001a
Last Level 1 BMB:0x01c00019 <---- (1)
Last Level II BMB:0x01c0001a <---- (2)
Last Level III BMB:0x00000000 <---- (3)
～～
********************************************************************
↑ここまで↑
上記ダンプに追記したコメント (1)、(2)、(3)が、それぞれ Level1～IIIに分
かれています。
ブロックアドレスを16進数から10進数に変換してみます。
Last Level 1 BMB:0x01c00019 ⇒ 25番目のブロック Last Level II BMB:0x01c0001a ⇒ 26番目のブロック Last Level III BMB:0x00000000 ⇒ 対象ブロックなし
さて何が分かるでしょうか？？？
まず、セグメントヘッダブロック（27番目）より若いブロックが、Level 1
Level II となっている事がわかりますね。
う～ん、だから・・・という感じですが、
続けて Level 1、Level IIのブロックダンプを取得してみます。
Level 1のブロックダンプ（25番目のブロック）の取得
alter system dump datafile 7 block 25;
Level 1（FIRST LEVEL BITMAP BLOCK）の抜粋（自動セグメント領域管理）
むむ！ブロック毎の空き状態が、見えちゃいました！
↓ここから↓ ******************************************************************** Start dump data blocks tsn: 9 file#: 7 minblk 25 maxblk 25 ～～ frmt: 0x02 chkval: 0x061f type: 0x20=FIRST LEVEL BITMAP BLOCK ～～ -------------------------------------------------------- DBA Ranges : -------------------------------------------------------- 0x01c00019 Length: 8 Offset: 0 0:Metadata 1:Metadata 2:Metadata 3:75-100% free 4:75-100% free 5:75-100% free 6:75-100% free 7:75-100% free ******************************************************************** ↑ここまで↑
取得したダンプの最後の 2行を見てください。
参照しているセグメント（ITI1.SUMMER_LEAF テーブル）は、
0 ～ 7 まで 8 ブロック使用してますね。
また、各ブロックの使用用途は、以下と読み取れそうです。
0:Metadata ⇒ Level 1 （FIRST LEVEL BITMAP BLOCK） 1:Metadata ⇒ Level II（SECOND LEVEL BITMAP BLOCK） 2:Metadata ⇒ セグメントヘッダブロック 3:75-100% free ⇒ 行 格納用 4:75-100% free ⇒ 行 格納用 5:75-100% free ⇒ 行 格納用 6:75-100% free ⇒ 行 格納用 7:75-100% free ⇒ 行 格納用
上記から、前回お伝えしたように、Level 1 のセグメント管理情報はブロック
毎の空き率を保持している事が確認できます。
では、続けて Level IIのブロックダンプ（26番目のブロック）の取得
alter system dump datafile 7 block 26;
Level II（SECOND LEVEL BITMAP BLOCK）の抜粋（自動セグメント領域管理）
ふむふむ。Level II のブロックが管理する Level 1 の情報を保持している
ようです。
↓ここから↓ ******************************************************************** Start dump data blocks tsn: 9 file#: 7 minblk 26 maxblk 26 ～～ frmt: 0x02 chkval: 0x46b9 type: 0x21=SECOND LEVEL BITMAP BLOCK ～～ L1 Ranges : -------------------------------------------------------- 0x01c00019 Free: 5 Inst: 1 ******************************************************************** ↑ここまで↑
取得したダンプの最後の行を見てください。
Level II のブロックが管理する Level 1 のブロックアドレスと空きブロッ
クがいくつあるかを保持しているようです。
今回は、セグメントヘッダにレベル分けして保持している情報がどのようにな
っているか見てきました。
次回は、一呼吸おいて従来のFREELIST管理について改めて復習する予定です。
ダンプの内容を覗く回が続きます。しばらくお付き合い下さい。
急に暖かくなってきました。
コートを着るか着ないか、毎朝迷う今日この頃。
桜満開まぢかの茅ヶ崎にて