共有プール領域に関する検証　その９

＜共有プールに関する検証　その9＞　ペンネーム　ダーリン

–　共有プールのフラグメンテーション　-－

さてさて、このたび以下のようなご質問をいただいた。

「共有プール内でデータやストアードプロシージャなど
の入れ替えが頻繁に発生すると、断片化が生じると思
います。この断片化の状況を知る方法はないでしょうか。」

これについては、前回・前々回で取り上げたX$KSMSPを用いて調べることが出
来る。
X$KSMSP表の各レコードは、共有プール内のチャンクを現している。よって、
これらを調べることで、フラグメントの状況を把握することが出来るのだ。

たとえば、以下のSQLは、共有プールのチャンク数を数えていることになる。

SQL> select count(*) from x$ksmsp;

  COUNT(*)
----------
     79160

この数を数えることで、全体的にフラグメントの発生状況を把握することがで
きる。但し、どの程度のチャンク数になると（フラグメントの多発による処理
速度の低下などの）問題を引き起こすかは、環境により異なるので一概には表
現できない。問題が発生した時点で、上記のようにカウントを取ってみると参
考になるだろう。

ちなみに、同じ環境でインスタンスを起動した直後のチャンク数は、以下のと
おりであった。

SQL> select count(*) from x$ksmsp;

  COUNT(*)
----------
      2140

インスタンス起動直後と比べてフラグメントが発生していることうかがえる。

上記について、もう少し細かく各カテゴリ毎に見てみると以下のとおりになる。

SQL> select count(*) from x$ksmsp;

SQL> select a.KSMCHCOM
  2        ,sum(a.chunk)   chunk
  3        ,sum(a.recr)    recr
  4        ,sum(a.freeabl) freeabl
  5        ,sum(a.sum)     sum
  6  from (
  7          select KSMCHCOM
  8                ,count(KSMCHCOM) chunk
  9                ,decode(KSMCHCLS,'recr',sum(KSMCHSIZ),null) recr
 10                ,decode(KSMCHCLS,'freeabl',sum(KSMCHSIZ),null) freeabl
 11                ,sum(KSMCHSIZ) sum
 12          from  x$ksmsp
 13          group by KSMCHCOM,KSMCHCLS) a
 14 group by a.KSMCHCOM;

KSMCHCOM              CHUNK       RECR    FREEABL        SUM
---------------- ---------- ---------- ---------- ----------
Global Context            1                   224        224
KGK contexts              2                  2376       2376
KGK heap                  2       3812                  3812
KGL handles           15071    4818416               4818416
KGLS heap               265      61292     212740     274032
KGSK scheduler            2       9652       4248      13900
KGSKI schedule            8        436      20916      21352
LISTEN ADDRESS            6                  1472       1472
PARAMETER ENTRY           5                   212        212
PARAMETER TABLE           1                  1032       1032
PL/SQL DIANA            724      11012     421552     432564
     ＜以下、省略＞
           ：
           ：
           ：
39行が選択されました。

上記の結果を、インスタンス起動直後の状態と比較してみるとたとえば以下の
ような違いが現れていることがわかる。

KSMCHCOM              CHUNK       RECR    FREEABL        SUM
---------------- ---------- ---------- ---------- ----------
（※1）
KGL handles             268      87404                 87404
（※2）
KGL handles           15071    4818416               4818416

（※1）
KGLS heap               131      69136      75788     144924
（※2）
KGLS heap               265      61292     212740     274032

（※1）
dictionary cach          82                128136     128136
（※2）
dictionary cach         199                164312     164312

（※1）
free memory              98                         32525012
（※2）
free memory           16015                         13904108

（※1）
library cache           820     122224     204468     326692
（※2）
library cache         26408    4903336    4820276    9723612

（※1）
sql area                289      82844     317968     400812
（※2）
sql area              20313     617196    7681996    8299192

※1：インスタンス起動直後
※2：処理経過後

上記については、いずれもチャンク数が増えていることから、断片化が発生し
ていると考えてよいだろう。

次回は”free memory”について、断片化の様子をみてみることにしよう。

以上夜も過ごしやすくなってきた茅ヶ崎にて

共有プール領域に関する検証 その９

共有プール領域に関する検証　その９