ASSMに関する検証 その８
＜ASSMに関する検証 その８＞
ペンネーム： サマー・リーフ
▼前回のおさらい
前回は、自動セグメント領域管理（ASSM）のメリットとして複数セッションか
ら同時にSQLを実行しブロック競合を起こす検証を行いました。
自動セグメント領域管理（ASSM）のメリットである、ブロック競合（セグメン
トヘッダの競合）が、FREELIST管理に比べ軽減される事が待機イベントの統計
から確認できましたね。
今回は、FREELIST管理におけるセグメントの storage句（”freelists”）を調
整して、各セグメント管理についてみていきましょう。
※本連載にてセグメントという表記がありますが、検証はテーブルのみを対象
としています。
■FREELIST管理セグメントの空きリスト（”freelists”）について
セグメント（例えば、テーブル）を作成する際、空きリスト数を調整するため
に storage句で指定するパラメータです。
storage句の “freelists” 値を指定しないと、最小値 1（デフォルト）と設定
されます。
“freelists” が ‘1’ の場合、構造的にはセグメントヘッダーブロックが空き
リストとなります。（マスターフリーリストとも呼ばれます。）
１つの空きリストでセグメントを管理する場合、複数セッションからの
SQL（INSERT、DELETE、UPDATE）によって、空きブロックの競合が発生しやす
くなります。この競合は、待機イベントとして現われパフォーマンスの劣化に
つながる可能性があります。
従って、複数の空きリストを作成する事により、空きブロックの競合を軽減し
させます。（マスターフリーリストに追加するフリーリストをプロセスフリー
リストと呼びます。）
■環境
※今回から諸事情により、環境を替えて検証していきます。
OS：Red Hat Enterprise Linux ES release 4
DB：Oracle10g EE Release 2
■検証
前回に続き、複数セッションから同時に SQL（INSERT）を実行して、各セグ
メントの管理方法を待機イベントに着目して比較してみましょう。
※準備としてテーブルに行データを格納した後、全行データを削除して空き
ブロックを発生させて検証します。
(1)自動セグメント領域管理（ASSM）⇒デフォルトでテーブル作成
(2)FREELIST管理 1 ⇒デフォルトでテーブル作成
(3)FREELIST管理 2 ⇒"freelists"を "3" でテーブル作成
※同時SQL実行数を見越して
"freelists"の値を 3 としています。
●各検証パターンで作成したテーブルの設定値
(1) FREELISTS ⇒ 設定されない
(2) FREELISTS ⇒ 1 （デフォルト）
(3) FREELISTS ⇒ 3
OWNER TABLE_NAME FREELISTS FREELIST_GROUPS
------ --------------- ---------- ---------------
ITI1 SUMMER_LEAF ←(1)
ITI2 SUMMER_LEAF 1 1 ←(2)
ITI2 SUMMER_LEAF_2 3 1 ←(3)
●”buffer busy waits” 待機イベント（STATSPACKレポートから抜粋）
⇒ 3セッションから同時 INSERT（各セッションから 10万件）
(1)自動セグメント領域管理（ASSM）
前回の検証に比べ、全行データ削除して空きブロックを増やしているの
で”buffer busy waits” としての待機回数が多く加算されています。
“buffer busy waits”待機ベントとは、同一バッファキャッシュへのアク
セス競合により待機回数が加算されるものでしたね。
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
-------------------- -------- ------ ---------- ------ --------
buffer busy waits 4,432 0 11 3 0.0
(2)FREELIST管理 1
自動セグメント領域管理（ASSM）と比較すると桁違いに、
“buffer busy waits” としての待機回数が加算されています。待機時間
も多い事がわかります。
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
-------------------- -------- ------ ---------- ------ --------
buffer busy waits 164,219 0 65 0 0.5
(3)FREELIST管理 2
(2)に比べ、”buffer busy waits” 待機イベントは、フリーリスト数を増
やした事によりブロック競合が、約 1/5 に軽減されています。
(1)と比較すると、このイベントの待機回数は、約 8 倍多い結果となり
ました。
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
-------------------- -------- ------ ---------- ------ --------
buffer busy waits 35,013 0 18 1 0.1
alter table summer_leaf storage(freelists );
同じテーブルに対し同時実行SQL数を把握して適正値を検討します。
この値は、動的に変更が可能です。
[まとめ]
前回の検証では、複数のセッションから同時に実行されるSQLを効率よく処理
できるのは、自動セグメント領域管理（ASSM）のテーブルに軍配があがりまし
た。ただし、チューニングせずにデフォルトでテーブルを作成する事が前提で
した。
今回は、同時にSQLが実行されるセッション数を見越して FREELIST管理のテー
ブルの”freelists”の値（フリーリスト数）を調整する事により、同一バッフ
ァキャッシュブロックへのアクセス競合を軽減できることを確認しました。
（ここは皆さん、既にご存知ですね。）
ただ、運用面からみると、テーブルを多数所有し複数のセッションから同時に
SQLが実行されるようなシステムにおいて、”freelists”の値（フリーリスト数
）の見極めをテーブル毎にするのは、DBA の負担が大きくなるでしょう。
結果としては、今回の検証でも自動セグメント領域管理（ASSM）のテーブルの
方が、待機イベントの回数が少なくなっています。
セッション数が少ない状態で検証しているので、もっとアクティビティの高い
システムでは、顕著に差が現われるかもしれません。
以上の検証結果、運用面からみても、自動セグメント領域管理（ASSM）の方が
メリットを享受できそうです。
今週は、ここまで
つま先立ちだった娘の自転車が、踵べったり付いてるのをみて
時の流れと成長の速さを感じた週末でした♪ 茅ヶ崎にて