ASSMに関する検証 その５
＜ASSMに関する検証 その５＞
ペンネーム： サマー・リーフ
▼前回のおさらい
自動セグメント領域管理（ASSM）では、２つのHWM（ Low、High HWM）の定義
と、なぜ保持しているか紹介しました。
・High HWM とは、”最終ブロックを管理する Level 1 の BMB “と定義されま
す。この Level 1 の BMBで管理する情報に、最終ブロックがどのブロック
か保持しています。
⇒上記で説明した最終ブロックが、FREELIST管理の HWMと同義となります
この最終ブロック以降が、未使用のブロックとしてOracle内部で解釈さ
れます。
・Low HWM とは、自動セグメント領域管理（ASSM）固有の HWM を指します。
⇒自動セグメント領域管理（ASSM）の特性上、Level 1 の BMB が、ブロッ
クの状態を使用ブロックと未使用ブロックを混在で管理する場合があり
ます。
従って、使用済み領域と未使用領域を明確にする為に必要な HWM です。
それでは、自動セグメント領域管理（ASSM）でセグメントを管理すると、
この２つの HWM がどのように振舞うか、説明していきます。
▼Low HWM ⇒ High HWM の位置（ブロックアドレス）が離れると？？
この現象は？？
High HWM 以降の未使用領域に行データを格納していく、ダイレクトインサー
トを利用すると発生しやすくなります。
※例えば、SqlLoader（ダイレクトパスモード）、APPENDヒント句を使用し
たINSERT処理が挙げられます。
次に、この現象の影響は？？
調べてみると、
“Low HWM とHigh HWMの位置（ブロックアドレス）が離れてしまうと、
Low HWM からHigh HWMの間は未使用ブロックが混在するため、Level 1 のBMB
の情報を検索しブロックの読み込みをする必要がある。”
とあります。
さらに
“Low HWM と High HWM の間もマルチ・ブロック・リードでブロックが読み込
まれるが、Level 1 の BMB の読み込みはシングル・ブロック・リードで行わ
れるため、全表走査での I/O 回数の増加につながる。”
ともありました。
どうも、自動セグメント領域管理（ASSM）は、行データの格納のされ方に
よって全表走査に注意する必要がありそうです。
それでは、以下の検証パターンにて、各セグメントの管理方法の HWM が、
どう保持されるかと、全表走査時の読込みブロック数を見てみましょう。
■環境
OS：WindowsXP
DB：Oracle10g EE Release 10.2.0.3
■検証パターン
1. 行データを10万件格納して比較してみます。
1.1 自動セグメント領域管理（ASSM）
セグメントヘッダから、High、Low HWM を確認できます。
むむ、冒頭で説明したように Low HWM と High HWM が離れる現象か？？
ダイレクトインサートなんかしてないのに・・・513ブロック離れている。
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Level 1 BMB for High HWM block: 0x01c0028a ← 650 番目のブロック Level 1 BMB for Low HWM block: 0x01c00089 ← 137 番目のブロック ******************************************************************* ↑ここまで↑
Level 1 の BMB から、セグメントの最終ブロックが確認できます。
↓ここから↓（Level 1 の BMB ダンプ抜粋：650 番目のブロック）
*******************************************************************
HWM Flag: HWM Set
Highwater:: 0x01c00309 ← 777 番目のブロック
*******************************************************************
↑ここまで↑
全表走査を実行し、ブロックの論理読込み数を確認してみます。
SELECT * FROM ITI1.SUMMER_LEAF;
統計
--------- -----------------
7375 consistent gets
1.2 FREELIST管理
セグメントヘッダから、HWM を確認できます。
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Highwater:: 0x020002bb ← 699 番目のブロック ******************************************************************* ↑ここまで↑
全表走査を実行し、論理読込みブロック数を確認してみます。
SELECT * FROM ITI2.SUMMER_LEAF;
統計
--------- -----------------
7357 consistent gets
[HWMについて]
同じ件数を格納しているのに HWMからは、自動セグメント領域管理（ASSM）
の方が、多くのブロックを確保している事がわかります。
自動セグメント領域管理（HWM） → 777 番目のブロック 先頭ブロック（Level 1 BMB）） → 9 番目のブロック FREELIST管理（HWM） → 699 番目のブロック 先頭ブロック（セグメントヘッダブロック） → 9 番目のブロック ※ HWM - 先頭ブロックの差分が、セグメントを構成する総ブロック数。
以下の２つの理由から 自動セグメント領域管理（ASSM）の方が、領域を多く
必要とします。
(1)ブロックを管理するビットマップ領域を必要とする。
(2)セグメントを構成するブロックの中に、未使用ブロックとして確保される
場合がある。
自動セグメント領域管理（ASSM）
[内訳]
セグメントヘッダブロック | 1 ブロック
Level 2 BMB | 1 ブロック
Level 1 BMB | 18 ブロック
未使用ブロック | 59 ブロック
使用済みブロック | 689 ブロック
--------------------------------------------------+-------------
総確保ブロック数 = HWM - セグメントヘッダブロック = 768 ブロック
FREELIST管理
[内訳]
セグメントヘッダブロック | 1 ブロック
使用済みブロック | 689 ブロック
--------------------------------------------------+-------------
総確保ブロック数 = HWM - セグメントヘッダブロック = 690 ブロック
[読込みブロック数について]
全表走査では HWM までのブロックを読込む為、FREELIST管理より多くの領域
を必要とする自動セグメント領域管理（ASSM）は、I/O 回数が多くなるのは
予想できますね。
次に、1.1で確認した Low HWM と High HWM をみると、513ブロック離れてい
るのがわかります。
実際にブロックの行データ格納状態を見てみると High HWM（650 番目のブロ
ック）まで “FULL” となっていました。
つまり、セグメントヘッダーのダンプから Low HWM と High HWM が離れてい
るように見えても 使用ブロック、未使用ブロックが混在しているブロックの
範囲が大きく離れていない場合には、読込みブロック数に対して大きな影響
にならないのではと検証結果から推測できます。
今回の検証は、順次 10万件の行データを格納してテストしましたが、注意す
るほどの問題点は見られませんでした。
次回は、2つめの検証パターンとして、データ件数を増やし Low HWM と
High HWM を故意に離してしまうような状態にして、どの程度の影響があるか
を掘り下げて行く予定です。
＜ASSMに関する検証＞と題して紹介してきました。
そろそろ折り返しです～～
初回から、自動セグメント領域管理（ASSM）の解りにくい構造や、注意点か
ら説明してしまったので、良いイメージが沸かない流れになってしまったか
なと感じています。
締めとして、9iからの新機能 → 10gR2から表領域作成時のデフォルトである
自動セグメント領域管理（ASSM）の良さを理解していただけるようにまとめ
ていきたいと思います。
連日の雨で、すっかり涼しくなりました。寒い？？
週末は、天気になって欲しいですねぇ～ 茅ヶ崎にて