RAC環境におけるロックダウンに関する考察 その２
＜RAC環境におけるロックダウンに関する考察 その２＞
ペンネーム ちょびひげ
データベースバッファがビジーになるような大量読み込みが発生し始めると、
急にLRU_FLAG=8、つまりホットオブジェクトが増え始めます。
前回の例で：
SQL> l
1 select count(*) cnt,lru_flag,sum(x_to_null)
2 from x$bh
3* group by lru_flag
SQL> /
CNT LRU_FLAG SUM(X_TO_NULL)
---------- ---------- --------------
4047 0 0
7694 2 0
9733 4 0
5022 6 0
8586 8 2300
となっていたのは、1ノードからの大量の全件検索によりコールドブロックを
大量に取得して行くうちにロックダウンに関連するオブジェクトがホットの
ものしか残らなかった状況です。
因みに、１ノードからの大量全件検索を発生させる前は；
CNT LRU_FLAG SUM(X_TO_NULL)
---------- ---------- --------------
13042 0 4212
2694 2 989
12 8 22
と、ほとんどがコールドブロックの状態になっていました。
■このことから分かるようにロックダウンとLRU_FLAGは直接関係していません
しかし、データベースバッファのヒット率が５０％とか低ければLRU_FLAG=8
に大量に移行され経験値の累計であるX_TO_NULLは本当に生きているロックダ
ウン累計に変わってきます。ですから、ヒット率が低い場合のロックダウン
統計は非常に有効です。逆にデータベースバッファヒット率が９８％以上の
サイトでロックダウン累計を眺めても意味がありません。
■ヒット率が９８％以上でも複数ノードでソーティングして見れば意味が出
てきます。
繰り返しになりますが、
１．複数ノード間で同一オブジェクトのロックダウン数が多い場合
２．上記１がインデックスの場合の方が影響度は大きい
３．突然カウントが上がったオブジェクトが存在する時間帯
４．上記１，２でロックダウン数が一定期間で上昇しているものが問題発見
の手がかりになります。
５．それがインデックスであれば重要な問題です。
６．一定期間の上昇が無いのなら「残っているだけの経験値」として無視す
べきです。
７．その場合は、上記３の突然現れたオブジェクトだけをパフォーマンス劣
化の手がかりとすべきです。
８．ロックダウンの数が多くても累計なので驚かない。
９．逆にロックダウンが少ない場合でも突然現れたオブジェクトであれば問
題発見の手がかりになる。
次回は、Oracle10gで見方の変わったロックダウン統計について、、、