ASSMに関する検証 その１０
＜ASSMに関する検証 その１０＞
ペンネーム： サマー・リーフ
▼前回までのおさらい
前回は、FREELIST管理におけるテーブルの storage句の”freelist groups”パ
ラメータを調整して各セグメント管理方法の違いを確認してきました。
“buffer busy waits”待機イベントの統計をもとに比較し、バッファブロック
の競合を考察しました。
さて、”freelist groups”パラメータとは？？
複数インスタンスからフリーリストへのアクセス競合を軽減する為のパラメー
タでした。
従って、複数インスタンスで構成される Real Apllication Cluster（以降、
RACと表記）環境で検証をしました。
前回の考察と違う着目点にて、各検証パターンを比較していきましょう。
■環境
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)自動セグメント領域管理（ASSM）
(2)FREELIST管理 1
(3)FREELIST管理 2
OWNER TABLE_NAME FREELISTS FREELIST_GROUPS
------ --------------- ---------- ---------------
ITI1 SUMMER_LEAF ←(1)
ITI2 SUMMER_LEAF 1 1 ←(2)
ITI2 SUMMER_LEAF_2 3 2 ←(3)
●グローバルキャッシュ関連（”gc* ***”）の待機イベントと実行時間
前回も触れました RACについて、おさらいします。
RAC環境では、複数のインスタンスが単一のデータベースにアクセスする構
成なので、キャッシュの一貫性を保つためにインスタンス間でキャッシュ
の内容（ブロック）を転送します。
この仕組みは、”グローバルキャッシュサービス”という RACの機能が司り
ます。
また、キャッシュの内容（ブロック）の転送を”キャッシュフュージョン”
と呼ばれる機能が実際に行います。
従って、グローバルキャッシュ関連（”gc* ***”）の待機イベントの統計か
らインスタンス間でキャッシュの要求、転送によるブロック競合を確認す
ることができます。
(1)自動セグメント領域管理（ASSM）
・ノード１では、”gcs log flush sync”が待機回数、待機秒数ともに一番
高い値となりました。
この待機イベントは、ログバッファの内容をREDOログファイルへ書き出
す際に待ちが発生したときにカウントされます。
キャッシュフュージョンが、キャッシュブロックを要求したノードへ更
新ブロックを転送する前に、転送する側のノードでログバッファの内容
をREDOログファイルへ書き出す動作をします。
従って、ノード１からノード２へ、更新ブロックを転送しているために
待機が発生したと考えられます。
・ノード２では、”gc cr block busy”が待機秒数で高い値となっています。
ノード１からノード２へ更新ブロックを転送する際に、ノード１で発生
する”gcs log flush sync”待機イベントが影響して、ブロック競合を起
こし待機が発生したと考えられます。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gcs log flush sync 1,354 85 24 18 0.0
gc buffer busy 155 2 13 86 0.0
gc current block busy 38 3 10 263 0.0
gc current block 2-way 154 1 4 26 0.0
▼実行時間
セッション(1) → Elapsed: 00:01:35.09
セッション(2) → Elapsed: 00:01:38.83
セッション(3) → Elapsed: 00:01:39.10
平均 → Elapsed: 00:01:37.34
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gc cr block busy 45 0 26 568 0.0
gc buffer busy 190 5 18 97 0.0
gc current block busy 37 8 12 334 0.0
gcs log flush sync 553 77 11 21 0.0
gc current block 2-way 766 0 10 13 0.0
▼実行時間
セッション(1) → Elapsed: 00:01:23.04
セッション(2) → Elapsed: 00:01:38.83
セッション(3) → Elapsed: 00:01:41.96
平均 → Elapsed: 00:01:34.61
(2)FREELIST管理 1
FREELIST管理、且つ フリーリストグループをデフォルトの 1 とした場
合、自動セグメント領域管理（ASSM）と比較すると、待機回数、待機時
間 共に大きな値になっています。
従って、ノード１からノード２へ、頻繁に更新ブロックを転送している
ために発生した待機が影響して自動セグメント領域管理（ASSM）に比べ
約1.8倍の処理時間となりました。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gc buffer busy 8,547 0 164 19 0.0
gcs log flush sync 6,081 45 78 13 0.0
gc current block busy 1,144 0 76 67 0.0
gc current multi block 1,741 0 30 17 0.0
request
gc current block 2-way 1,787 0 11 6 0.0
▼実行時間
セッション(1) → Elapsed: 00:02:26.80
セッション(2) → Elapsed: 00:02:33.19
セッション(3) → Elapsed: 00:03:11.33
平均 → Elapsed: 00:02:43.44
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gc buffer busy 9,323 0 202 22 0.0
gcs log flush sync 6,045 45 76 13 0.0
gc current block busy 1,067 0 74 69 0.0
gc current multi block 936 0 33 35 0.0
request
gc current block 2-way 2,019 0 14 7 0.0
gc current grant busy 88 0 3 31 0.0
▼実行時間
セッション(1) → Elapsed: 00:03:10.50
セッション(2) → Elapsed: 00:03:10.50
セッション(3) → Elapsed: 00:03:10.82
平均 → Elapsed: 00:03:10.60
(3)FREELIST管理 2
FREELIST管理、且つ フリーリストグループをインスタンス数に合わせて
調整した結果をみると、待機回数、待機時間共に検証パターンで一番小
さい値になりました。
しかし、自動セグメント領域管理（ASSM）に比べ 約1.2倍 長い処理時間
となりました。
前回、考察した”buffer busy waits” 待機イベントと”gc* ***” 待機イ
ベントの統計情報からしても、フリーリストグループを調整した方が効
率よく処理されているように見えましたが、実行時間が長くなる原因が
あるようです。
[ノード１]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gc current block 2-way 579 1 6 11 0.0
gc current grant busy 97 0 6 61 0.0
gc cr block busy 8 0 1 127 0.0
gc buffer busy 5 20 1 199 0.0
gcs log flush sync 49 90 1 18 0.0
▼実行時間
セッション(1) → Elapsed: 00:01:55.81
セッション(2) → Elapsed: 00:01:59.09
セッション(3) → Elapsed: 00:01:59.84
平均 → Elapsed: 00:01:58.58
[ノード２]
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
------------------------- ------- ------ ---------- ------ ------
gc current grant busy 96 0 3 35 0.0
gc current block 2-way 431 0 2 5 0.0
gcs log flush sync 57 72 1 24 0.0
▼実行時間
セッション(1) → Elapsed: 00:01:51.95
セッション(2) → Elapsed: 00:01:54.19
セッション(3) → Elapsed: 00:01:54.37
平均 → Elapsed: 00:01:53.50
[まとめ]
グローバルキャッシュ関連（”gc* ***”）待機イベントの統計から以下の順で
ブロックの競合が、多く発生する結果となりました。
(2)FREELIST管理、且つ デフォルト値（FREELIST 1、FREELIST GROUPS 1）
↓
(1)自動セグメント管理（ASSM）
↓
(3)FREELIST管理、且つ FREELIST 3、FREELIST GROUPS 2
前回の検証結果の考察と同様に、FREELIST管理、且つ セグメント作成時に
Storage句でパラメータを調整する方が、RAC環境で発生しがちなブロック競合
を減らすことができそうです。
が・・・・
検証結果からは、ブロック競合によって発生する待機イベントが一番少なくな
っているにもかかわらず、なぜ実行時間が遅くなってしまったのでしょうか？
環境による誤差か？
何か、他に原因が？
謎を残して、次回に持ち越すのは心苦しいですが、
今日はここまで。
もうすぐ、梅雨入り・・・
“つゆいり”って変換すると”入梅”！知ってました？ 茅ヶ崎より