RAC環境におけるロックダウンに関する考察 その2

<RAC環境におけるロックダウンに関する考察 その2>
ペンネーム ちょびひげ

データベースバッファがビジーになるような大量読み込みが発生し始めると、
急に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ノードからの大量の全件検索によりコールドブロックを
大量に取得して行くうちにロックダウンに関連するオブジェクトがホットの
ものしか残らなかった状況です。

因みに、1ノードからの大量全件検索を発生させる前は;

       CNT   LRU_FLAG SUM(X_TO_NULL)
---------- ---------- --------------
     13042          0           4212
      2694          2            989
        12          8             22

と、ほとんどがコールドブロックの状態になっていました。

■このことから分かるようにロックダウンとLRU_FLAGは直接関係していません

しかし、データベースバッファのヒット率が50%とか低ければLRU_FLAG=8
に大量に移行され経験値の累計であるX_TO_NULLは本当に生きているロックダ
ウン累計に変わってきます。ですから、ヒット率が低い場合のロックダウン
統計は非常に有効です。逆にデータベースバッファヒット率が98%以上の
サイトでロックダウン累計を眺めても意味がありません。

■ヒット率が98%以上でも複数ノードでソーティングして見れば意味が出
てきます。
繰り返しになりますが、

1.複数ノード間で同一オブジェクトのロックダウン数が多い場合
2.上記1がインデックスの場合の方が影響度は大きい
3.突然カウントが上がったオブジェクトが存在する時間帯
4.上記1,2でロックダウン数が一定期間で上昇しているものが問題発見
    の手がかりになります。
5.それがインデックスであれば重要な問題です。
6.一定期間の上昇が無いのなら「残っているだけの経験値」として無視す
    べきです。
7.その場合は、上記3の突然現れたオブジェクトだけをパフォーマンス劣
    化の手がかりとすべきです。
8.ロックダウンの数が多くても累計なので驚かない。
9.逆にロックダウンが少ない場合でも突然現れたオブジェクトであれば問
    題発見の手がかりになる。

次回は、Oracle10gで見方の変わったロックダウン統計について、、、