ASSMに関する検証 その６
＜ASSMに関する検証 その６＞
ペンネーム： サマー・リーフ
▼前回のおさらい
自動セグメント領域管理（ASSM）では、２つのHWM（Low、High HWM）につい
て、FREELIST管理と比較してみてきました。
High HWM とは、ダイレクトインサートなどで、セグメントの最終ブロックの
ブロックアドレスを把握する為に必要でした。これは、読者の皆様もご存知
の FREELIST管理でいう HWM と同じでしたね。
もう 1つの Low HWM は、自動セグメント領域管理（ASSM）の特性上必要な
HWM でした。
↓詳細は、バックナンバーを参照してください。
＜ASSMに関する検証 その４＞
https://old.insight-tec.com/mailmagazine/ora3/vol334.html
さっそく前回の続きとして、以下の検証パターンにて 各セグメントの管理方
法の HWM が、どう保持されるかと、全表走査時の読込みブロック数を見てみ
ましょう。
■環境
OS：WindowsXP
DB：Oracle10g EE Release 10.2.0.3
■検証パターン
2. 行データをSQL*Loader使用（ダイレクトモード）してHWM 以降に格納し、
各セグメントの管理方法を比較します。
2.1 自動セグメント領域管理（ASSM）
まずは、自動セグメント領域管理（ASSM）の表領域に作成した テーブルを
TRUNCATEします。（Low、High HWMを引き下げます。）
次に、初期で 10万件の行データを格納！
セグメントヘッダのダンプを見ると、513ブロック Low HWM ⇒ High HWMの
位置が離れている事が確認できますね。
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Level 1 BMB for High HWM block: 0x01c0028a ← 650番目のブロック Level 1 BMB for Low HWM block: 0x01c00089 ← 137番目のブロック ******************************************************************* ↑ここまで↑
SQL*Loader（ダイレクトモード）を使用して、HWM 以降に行データを格納し
ます。（10万件ずつ、100万件まで行データ追加！）
Low HWMが変わらずに、High HWM が引き上がるはずです。
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Level 1 BMB for High HWM block: 0x02801b8a ← 7050番目のブロック Level 1 BMB for Low HWM block: 0x02801b8a ← 7050番目のブロック ******************************************************************* ↑ここまで↑
あ”～
Low HWM が、High HWM 同じ！？
自動セグメント領域管理（ASSM）の注意点が・・・
調べてみると、10gR1からダイレクトロード時に、引きあがった High HWM
に Low HWM の位置を引き上げる動作をする仕様となっていました。
また、ダイレクトロード時の Low HWM の位置調整は、隠しパラメータで制
御できるようです。（10gR1からのデフォルト）
※以下のSQLで、該当の隠しパラメータを確認できます。
select
a.ksppinm "PARAMETER",
b.ksppstvl "VALUE"
from
x$ksppi a, x$ksppcv b
where
a.indx = b.indx and
a.ksppinm like '%_hwm_sync%';
PARAMETER VALUE
-------------------- ------
_enable_hwm_sync TRUE ←Low HWM 位置をHigh HWMまで
引き上げる。
_hwm_sync_threshold 10 ←セグメントサイズの割合で
Low HWM 位置の引き上げを抑止。
次に、前回の検証と同様に全表走査を実行し、論理読込みブロック数を確
認してみます。（100万件 行データ格納）
SELECT * FROM ISUMMER_LEAF;
統計
--------- -----------------
73258 consistent gets
2.2 FREELIST管理
FREELIST管理の表領域に作成した テーブルをTRUNCATEします。
（HWM を引き下げます。）
次に、初期で 100万件の行データを格納！
セグメントヘッダのダンプを見ると、HWM 確認できます。
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Highwater:: 0x02c002bb ← 699番目のブロック ******************************************************************* ↑ここまで↑
SQL*Loader（ダイレクトモード）を使用して、HWM 以降に行データを格納し
ます。（10万件ずつ、100万件まで行データ追加！）
↓ここから↓（セグメントヘッダのダンプ抜粋） ******************************************************************* Highwater:: 0x02c01b21 ← 6945番目のブロック ******************************************************************* ↑ここまで↑
前回の検証と同様に、全表走査を実行し、論理読込みブロック数を確認し
てみます。（100万件 行データ格納）
SELECT * FROM SUMMER_LEAF;
統計
--------- -----------------
73199 consistent gets
[まとめ]
前回の検証結果と合わせて、再度まとめます。
全表走査では HWM までのブロックを読込むので、FREELIST管理より多く管理
情報の領域を必要とする自動セグメント領域管理（ASSM）のセグメントは、
I/O 回数が多くなる結果となりました。
今回の検証では、SQL*Loader（ダイレクトモード）の使用で行データを格納し
たため、自動セグメント領域管理（ASSM）は、Low、High HWM が離れてしまい
I/O が増加すると予想していましたが、顕著に見られませんでした。
これは、自動セグメント領域管理（ASSM）の検証結果で、お伝えしたように
ダイレクトインサートなどを実行すると 10gR1から Low HWM の位置を
High HWM に合わせる事により全表走査への影響を抑えるようになったためと
考察できますね。
[！補足情報！]
検証中に調べた、隠しパラメータについて補足します。
9iR2（厳密に、9.2.0.8）では、_enable_hwm_sync が “FALSE”になります。
では、自動セグメント領域管理（ASSM）のセグメントが、”_enable_hwm_sync”
が、true と false の場合で比較してみましょう。
初期で 10万件の行データを格納し、続けて SQL*Loader（ダイレクトモード）
を使用して、HWM 以降に 10万件ずつ、100万件まで行データ追加してみます。
—————————-
–“_enable_hwm_sync”=true;
—————————-
— HWM の状態
↓ここから↓（セグメントヘッダのダンプ抜粋） ***************************************************************** Level 1 BMB for High HWM block: 0x01c0028a ← 650番目のブロック Level 1 BMB for Low HWM block: 0x01c00089 ← 137番目のブロック ***************************************************************** ↑ここまで↑
--全表走査時の論理読込みブロック数
統計
--------- -----------------
73258 consistent gets
--セグメントブロックの状態
未フォーマットブロック数 = 0
0 - 25% 空きブロック数 = 0
25- 50% 空きブロック数 = 0
50- 75% 空きブロック数 = 0
75-100% 空きブロック数 = 60
100% 使用ブロック = 6934
隠しパラメータを変更します。
alter system set "_enable_hwm_sync"=false; ---------------------------- --"_enable_hwm_sync"=false; ----------------------------
— HWM の状態
↓ここから↓（セグメントヘッダのダンプ抜粋）
*****************************************************************
Level 1 BMB for High HWM block: 0x02801b8a ← 7050番目のブロック
Level 1 BMB for Low HWM block: 0x0280020a ← 522番目のブロック
*****************************************************************
↑ここまで↑
--全表走査時の論理読込みブロック数
統計
--------- -----------------
73332 consistent gets
--セグメントブロックの状態
未フォーマットブロック数 = 46
0 - 25% 空きブロック数 = 0
25- 50% 空きブロック数 = 0
50- 75% 空きブロック数 = 0
75-100% 空きブロック数 = 14
100% 使用ブロック = 6934
“_enable_hwm_sync”=false の方に着目すると・・・
・Low HWM と High HWM が大きく離れている。
・全表走査時の論理読込みブロック数が増えてている。
・論理読込みブロック数が増えている。
・未フォーマットのブロックが存在する。
比較結果から考察すると、Low HWM と High HWM の間に 未フォーマットブロ
ックが存在し、未フォーマットブロックを読込む際に 論理読込みブロック数
が増えることが確認できます。
行データのレングス、件数などの違いにより、顕著に上記状態になる事も想
定できます。
現在、9iR2（厳密に、9.2.0.8）をご使用の読者の方が、いらっしゃるかと
思います。
9iR2（厳密に、9.2.0.8）の環境で、自動セグメント領域管理（ASSM）を採用
してデータベースを設計している場合は、セグメントの状態を定期的に監視
してメンテナンスする必要があるかもしれません。
今日は、ここまで。
今週末からＧＷです！
が、高速の大渋滞に巻き込まれる覚悟をせねば・・・ 茅ヶ崎にて