動的SGAと自動メモリ管理に関する検証 その6

投稿日: 2004年9月01日

<動的SGAと自動メモリ管理に関する検証 その6>
ペンネーム:アイスケーキ

オリンピックも終わりホット一息の毎日ですが今回も引き続き動的SGAと自動
メモリ管理について検証をします。

◆環境
Windows XP Pro + SP1
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 – Prod

◆はじめに
Oracle Database 10g の動的SGAの動作として共有プール、Javaプール、ラー
ジプール領域が不足した場合デフォルト・バッファキャッシュから領域を融通
します。

では、共有プール、Javaプール、ラージプールが不足したと判断するにはどの
ようなタイミングで何を基礎値として行っているのでしょうか?

共有プールをターゲットにして探ってみます。

予想できるタイミングとしては
○ライブラリキャッシュのヒット率が低下した場合
○ディクショナリキャッシュのヒット率が低下した場合
○shared_pool_reserved以上の連続域の獲得が必要になった場合
○MTS環境の時、UGAを共有プールに獲得している場合でUGAの拡張が必要にな
った場合
などです。

全部はできないので、ライブラリキャッシュのヒット率が低下した場合につい
て内部動的ビューがどのような値になっているか見てみます。

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

◆ライブラリキャッシュのヒット率が低下した場合

(1)共有プールをクリアします(alter system flush shared_pool)

(2)ライブラリキャッシュヒット率が良好であることを確認します。

select sum(pins) total_pins, sum(reloads) total_reloads,
to_char((1-sum(reloads)/sum(pins))*100,'990.99') || '%' "hit Lib"
from v$librarycache;

TOTAL_PINS TOTAL_RELOADS hit Lib
---------- ------------- --------
     12989           204   98.43%

(3)バインド変数を使用しないSQLを大量に流します。

(4)ライブラリキャッシュのヒット率が低下しました。

TOTAL_PINS TOTAL_RELOADS hit Lib
---------- ------------- --------
     52429          8970   82.89%

(5)ディクショナリキャッシュヒット率が良好であることを確認します。

select sum(gets) total_gets, sum(getmisses) total_misses,
to_char((1-sum(getmisses)/sum(gets))*100,'990.99') || '%' "hit Dic"
from v$rowcache;

TOTAL_GETS TOTAL_MISSES hit Dic
---------- ------------ --------
     64511         6543   89.86%

(6)共有プールの拡張が発生しました。

select to_char(START_TIME,'YYYY/MM/DD HH24:MI:SS') as Time,
COMPONENT,OPER_TYPE,(FINAL_SIZE-INITIAL_SIZE)/1024/1024 as Gap,
FINAL_SIZE/1024/1024 as "Final Size",STATUS
from V$SGA_RESIZE_OPS;

TIME                COMPONENT            OPER_TYPE  GAP Final Size STATUS
------------------- -------------------- --------- ---- ---------- --------
2004/08/31 14:40:56 DEFAULT buffer cache SHRINK      -4         76 COMPLETE
2004/08/31 14:40:56 shared pool          GROW         4         40 COMPLETE

2004/08/31 14:42:00 DEFAULT buffer cache SHRINK      -4         72 COMPLETE
2004/08/31 14:42:00 shared pool          GROW         4         44 COMPLETE

★☆★☆★☆

以上は先週までもやっていた内容なのでイメージが掴みやすいと思います。
ライブラリキャッシュのヒット率低下が共有プールの拡張判断の1つであるこ
とは確かのようです。但し、何パーセントがしきい値なのかは不明です。

しきい値を探るうえで、v$shared_pool_advice 動的ビューを見てみます。
これには共有プールの解析時間の見積りに関する情報が格納されています。
(dba_hist_shared_pool_advice にはその履歴が格納されます)

SQL> desc v$shared_pool_advice
 名前                          NULL? 型
 ----------------------------- ----- ------
 SHARED_POOL_SIZE_FOR_ESTIMATE       NUMBER
 SHARED_POOL_SIZE_FACTOR             NUMBER
 ESTD_LC_SIZE                        NUMBER
 ESTD_LC_MEMORY_OBJECTS              NUMBER
 ESTD_LC_TIME_SAVED                  NUMBER
 ESTD_LC_TIME_SAVED_FACTOR           NUMBER
 ESTD_LC_LOAD_TIME                   NUMBER ←10gにて追加
 ESTD_LC_LOAD_TIME_FACTOR            NUMBER ←10gにて追加
 ESTD_LC_MEMORY_OBJECT_HITS          NUMBER

タイトルは上記項目順にA~Iにしています。

(初期起動時:共有プール36MB)

   A       B    C     D    E      F    G       H      I
---- ------- ---- ----- ---- ------ ---- ------- ------
  32   .8889    4   780    6      1    6       1   1444
★36       1    4   780    6      1    6       1   1444
  40  1.1111    4   780    6      1    6       1   1444
  44  1.2222    4   780    6      1    6       1   1444
  48  1.3333    4   780    6      1    6       1   1444
  52  1.4444    4   780    6      1    6       1   1444
  56  1.5556    4   780    6      1    6       1   1444
  60  1.6667    4   780    6      1    6       1   1444
  64  1.7778    4   780    6      1    6       1   1444
  68  1.8889    4   780    6      1    6       1   1444
  72       2    4   780    6      1    6       1   1444

(1回目の拡張時:共有プール40MB)

   A       B    C     D    E      F    G       H      I
---- ------- ---- ----- ---- ------ ---- ------- ------
  32      .8    4  1067    7      1    8       1   1646
  36      .9    7  1788    7      1    8       1   1658
★40       1    8  2145    7      1    8       1   1658
  44     1.1    8  2145    7      1    8       1   1658
  48     1.2    8  2145    7      1    8       1   1658
  52     1.3    8  2145    7      1    8       1   1658
  56     1.4    8  2145    7      1    8       1   1658
  60     1.5    8  2145    7      1    8       1   1658
  64     1.6    8  2145    7      1    8       1   1658
  68     1.7    8  2145    7      1    8       1   1658
  72     1.8    8  2145    7      1    8       1   1658
  76     1.9    8  2145    7      1    8       1   1658
  80       2    8  2145    7      1    8       1   1658

(2回目の拡張時:共有プール44MB)

   A       B    C     D    E      F    G       H      I
---- ------- ---- ----- ---- ------ ---- ------- ------
  36   .8182    8  2544   13  .9286   25  1.0417  30467
★44       1   15  4693   14      1   24       1  34032
  52  1.1818   22  6761   14      1   24       1  34150
  60  1.3636   22  6810   14      1   24       1  34150
  68  1.5455   22  6810   14      1   24       1  34150
  76  1.7273   22  6810   14      1   24       1  34150
  84  1.9091   22  6810   14      1   24       1  34150
  92  2.0909   22  6810   14      1   24       1  34150

レコード数は共有プールサイズに応じて等間隔が決まります。
(A)が見積り用共有プールサイズです。現行共有プールサイズと一致したレコー
ドが(B)のサイズ要因=1となって分布レコードが作成されているようです。

以下は目に見えて増加がある項目です。
(C)はライブラリキャッシュに使用中のメモリー見積り値
(D)はライブラリキャッシュメモリーオブジェクト数の見積り数値
(E)はメモリーから消去されたオブジェクトの再ロード見積り秒値
(G)は共有プール内で解析を行う場合の経過時間の見積り秒値
(I)はライブラリキャッシュメモリオブジェクトが検出された回数見積り値

なんだか動的ビューの説明になってしまいましたが共有プールの状況を把握す
るには有効なビューではないでしょうか?

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

今回で動的SGAについては一区切りとしたいと思います。

少しは涼しくなった茅ヶ崎より