ASSMに関する検証 その１１
＜ASSMに関する検証 その１１＞
ペンネーム： サマー・リーフ
▼前回までのおさらい
Real Apllication Cluster（以降、RACと表記）環境で、自動セグメント管理
（ASSM）と FREELIST管理の各表領域に作成したテーブルに対し、トランザク
ションを発生させて処理結果を比較してきました。
3回に渡って考察している検証パターンは、以下です。
(1)自動セグメント管理（ASSM）
→テーブル作成時は、デフォルト。
(2)FREELIST管理 1
→テーブル作成時は、デフォルト。
(3)FREELIST管理 2
→テーブル作成時に、Storage句で指定するパラメータを調整。
※同時SQL実行数を想定し、”FREELISTS”の値を 3。
※同時アクセスインスタンス数を想定し”FREELIST GROUPS”の値を 2。
■前回までの各セグメント管理方法の比較ポイント
・”buffer busy waits” 待機イベント
→キャッシュされているブロック競合の頻度を確認。
空きリスト競合は、ブロック競合に現れるために指標としています。
[ブロック競合が少ない順]
◎(3)FREELIST管理 2
↓
(1)自動セグメント管理（ASSM）
↓
(2)FREELIST管理 1
・グローバルキャッシュ関連（”gc* ***”）の待機イベント
→インスタンス間でキャッシュの要求、転送によるブロック競合を確認。
[グローバルキャッシュの競合が少ない順]
◎(3)FREELIST管理 2
↓
(1)自動セグメント管理（ASSM）
↓
(2)FREELIST管理 1
・実行時間（３セッションから）
[実行時間の短い順]
◎(1)自動セグメント管理（ASSM）
↓
(3)FREELIST管理 2
↓
(2)FREELIST管理 1
[まとめ]
ブロックの競合、グローバルキャッシュの競合が、待機イベントの統計
情報からみて効率良く処理されているFREELIST管理 2（テーブルの
Storage句を調整）よりも、自動セグメント管理（ASSM）の方が、実行
時間が短くなる結果となりました。
引き続き、ブロックの競合、グローバルキャッシュの競合で発生する待機イベ
ントが、少ないのに実行時間が長くなってしまう現象を検証結果から見ていき
ましょう。
■環境
OS ：Red Hat Enterprise Linux ES release 4
DB ：Oracle10g EE Release 2（ 2 NODE RAC）
■検証
↓↓↓ 検証の前提、パターンは、バックナンバーを参照してください。 ↓↓
＜ASSMに関する検証 その９＞
https://old.insight-tec.com/mailmagazine/ora3/vol339.html
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
●各検証パターンで作成したテーブルの設定値
(1) FREELIST_GROUPS ⇒ 設定されない（ASSMでは設定不要）
(2) FREELIST_GROUPS ⇒ 1 （デフォルト）
(3) FREELIST_GROUPS ⇒ 2 （RACを構成するノード × 2）
OWNER TABLE_NAME FREELISTS FREELIST_GROUPS
------ --------------- ---------- ---------------
ITI1 SUMMER_LEAF ←(1)
ITI2 SUMMER_LEAF 1 1 ←(2)
ITI2 SUMMER_LEAF_2 3 2 ←(3)
●REDOログファイル関連（”log ***”）の待機イベント
先に、REDOログファイル関連の待機イベントを説明します。
“log file parallel write” 待機イベント
REDOレコードをログバッファからREDOログファイルに書き込もうとし
て待ちになっている状態です。
複数のREDOログファイルメンバへの書き込みは、パラレルで書き込ま
れます。
“log buffer space” 待機イベント
ログバッファにデータを書き込む速度が、ログライタープロセスによ
る書出し速度を上回るため、ログバッファ内の領域を確保しようと
して待ちになっている状態です。
“log file sequential read” 待機イベント
REDOレコードをREDOログファイルから読み取る際に待ちになっている
状態です。
“log file switch (checkpoint incomplete)” 待機イベント
これは、チェックポイントが終わる前に REDOログを再利用しようとし
てログスイッチが待ちになっている状態です。
(1)自動セグメント領域管理（ASSM）
“log file sequential read” 待機イベントが、両ノードにて発生してい
ます。
内部的に、REDOレコードをREDOログファイルから読み取る際に待機イベ
ントが発生しているようです。
検証環境は、２グループ、２メンバのREDOログファイルの構成となって
いるため複数メンバーにREDOレコードを書き込みに行く際に
“log file parallel write” 待機イベントが発生しています。
ログバッファの内容をREDOログファイルに書き込みが終わる前に、ログ
バッファの領域を確保しようとして”log buffer space” 待機イベントが
発生しています。
検証では、同時SQL（INSERT）で負荷をかけているので、結果として
“log buffer”初期化パラメータで確保したログバッファーの領域が少な
かったと考えられます。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log file sequential read 231 0 96 415 0.0
log file parallel write 307 0 73 239 0.0
log buffer space 268 3 71 266 0.0
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log file sequential read 173 0 85 489 0.0
log file parallel write 302 0 73 242 0.0
log buffer space 248 5 60 240 0.0
(2)FREELIST管理 1
(1)と同様に、検証環境は ２グループ、２メンバのREDOログファイルの
構成となっているため複数メンバーにREDOレコードを書き込みに行く際
に”log file parallel write” 待機イベントが発生しています。
(1)と比較すると、待機回数が増えて、平均の待機時間が少なっています。
前回までの検証結果からすると、ブロックの競合、グローバルキャッシ
ュの競合が、待機イベントの統計として現れているので、実行時間は長
くなる結果となっています。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log file parallel write 2,467 0 92 37 0.0
log file sequential read 162 0 58 360 0.0
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log file parallel write 2,501 0 83 33 0.0
log file sequential read 162 0 53 325 0.0
(3)FREELIST管理 2
(1)と同様に、”log buffer space” 待機イベントが発生し、両ノード共
に待機時間が、大きくなっています。
ブロック競合が少ないのに、実行時間が長くなってしまった理由の一つ
と考えられます。
新たに、”log file switch (checkpoint incomplete)” 待機イベントが、
発生しています。
頻繁にログスイッチが、発生して待機イベントとして現れているようで
す。
検証では、同時SQL（INSERT）で負荷をかけているので、REDOレコードが
多く生成され、結果としてREDOログファイルのサイズが小さかったと考
えられます。
“log file sequential read” 待機イベントが、両ノードにて発生してい
ます。
内部的に、REDOレコードをREDOログファイルから読み取る際に待機イベ
ントが発生しているようです。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log buffer space 445 8 148 332 0.0
log file switch 120 94 114 953 0.0
(checkpoint incomplete)
log file sequential read 206 0 107 518 0.0
log file parallel write 248 0 78 316 0.0
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
log buffer space 470 7 126 268 0.0
log file switch 131 90 122 930 0.0
(checkpoint incomplete)
log file sequential read 175 0 94 539 0.0
log file parallel write 272 0 76 280 0.0
[まとめ]
前回は、自動セグメント領域管理（ASSM）と比較して、FREELIST管理 2（テー
ブル作成時にStorage句を調整）は、グローバルキャッシュの競合に関連する
待機イベントが少ないのに、実行時間が長いという検証結果となりました。
この理由は、インスタンス間でのグローバルキャッシュの競合が少なくても
REDOレコードの生成、REDOログへの書き込みが頻繁に発生していることから、
REDOログ関連の待機イベントによって実行時間が長くなっていたと検証結果か
ら考えられます。
全般的に待機イベントを確認して、REDOログファイル関連の待機イベントが
発生しているようでしたら 初期化パラメータ（”log buffer”）や、REDOログ
ファイルのサイズの見直す必要があるかもしれません。
FREELIST管理で作成したテーブルは、Storage句のパラメータを調整すること
により、ブロック競合を軽減することができます。
繰り返しになりますが、パラメータの値の決定にはテーブルへの同時アクセス
数や、同時アクセスインスタンス数の把握が必要です。
逆に 自動セグメント管理では、Storage句の値を指定せずにテーブルを作成し
てもブロック競合を抑えられ、なにも調整しない FREELIST管理よりも効率良
く処理される結果となっています。
今日は、ここまで
来週は、本連載のまとめとして最終回を予定しています。
もう少しの間、お付き合いください。 茅ヶ崎にて