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

投稿日: 2002年8月21日

<共有プールに関する検証 その5> ペンネーム ダーリン

– V$SQLAREA と 子カーソル --

前回は、SQLの親カーソルの情報をメモリ上で追いかけてみた。
今回は、まず子カーソルの情報を探してみる。

以下は前回取得したダンプファイル内の、親カーソルの部分の抜粋である。

*************************************************************************

LIBRARY OBJECT HANDLE: handle=821e121c       <------(※1)
name=select * from emp
hash=b382f8a6 timestamp=08-06-2002 09:41:20
namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/[12010000]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch=0
lwt=821e1234[821e1234,821e1234] ltm=821e123c[821e123c,821e123c]
pwt=821e124c[821e124c,821e124c] ptm=821e12a4[821e12a4,821e12a4]
ref=821e1224[821e1224, 821e1224] lnd=821e12b0[821e12b0,821e12b0]
  LOCK OWNERS:
     lock     user  session count mode flags
  -------- -------- -------- ----- ---- ------------------------
  82451088 82c9e4dc 82c9e4dc     1 N   [00]
  LIBRARY OBJECT: object=809b8cf4
  type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
  CHILDREN: size=16
  child#    table reference   handle
  ------ -------- --------- --------
      0 809b8e88  8079344c 819443ec       <------(※2)
  DATA BLOCKS:
  data#     heap  pointer status pins change alloc(K)  size(K)
  ----- -------- -------- ------ ---- ------ -------- --------
     0 81851570 809b8d78 I/P/A     0 NONE       0.80     1.05

*************************************************************************

ここで、関連がありそうな情報はというと、”child#”(※2)の部分であろうか。
そこで、”child#”の”handle”の部分に表示される値を検索してみよう。

すると、以下の部分が検索されるはずである。

*************************************************************************

LIBRARY OBJECT HANDLE: handle=819443ec       <------(※3)
namespace=CRSR flags=RON/KGHP/PN0/[10010000]
kkkk-dddd-llll=0000-0041-0041 lock=N pin=0 latch=0
lwt=81944404[81944404,81944404] ltm=8194440c[8194440c,8194440c]
pwt=8194441c[8194441c,8194441c] ptm=81944474[81944474,81944474]
ref=819443f4[8079344c, 8079344c] lnd=81944480[81944480,81944480]
  CHILD REFERENCES:
  reference latch flags
  --------- ----- -------------------
    8079344c     0 CHL[02]
  LOCK OWNERS:
      lock     user  session count mode flags
  -------- -------- -------- ----- ---- ------------------------
  82450f20 82c9e4dc 82c9e4dc     1 N   [00]
  LIBRARY OBJECT: object=814f8670           <------(※4)
  type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
  DEPENDENCIES: count=1 size=16
  dependency#    table reference   handle position flags
  ----------- -------- --------- -------- -------- -------------------
             0 814f882c  814f8764 823802d0       14 DEP[01]
  ACCESSES: count=1 size=16
  dependency# types
  ----------- -----
             0 0009
  TRANSLATIONS: count=1 size=16
  original    final
  -------- --------
  823802d0 823802d0
  DATA BLOCKS:
  data#     heap  pointer status pins change alloc(K)  size(K)
  ----- -------- -------- ------ ---- ------ -------- --------
       0 81068d60 81c83fb8 I/P/A     0 NONE       1.06     1.64
       6 814f8704 8108f3c4 I/-/A     0 NONE       4.36     5.13

*************************************************************************

つまり、これが子カーソルの情報である。
親カーソルの情報と比較して、SQL文自体が表示されなかったり、情報がいく
らか多かったりしている。
また、子カーソルが複数存在する場合は、親カーソルの”child#”(※2)の部
分に複数行表示され、それぞれ、同様に子カーソルを探すことが出来る。

なお、今回子カーソルを探す際に使用した子カーソルの”handle”(※3)は
V$SQL表の”CHILD_ADDRESS”カラムに表示される値であるから、この値を元に
検索することも出来る。

さて、親カーソルよりいくらか情報が多いことは上記の抜粋からわかると思
うが、その中でも、興味深いのが”DEPENDENCIES”(※4)で、おそらく賢明な
読者諸氏はお分かりだろうが、これは、このカーソル(SQL)の関連オブジェ
クトの情報である。

子カーソルを探したときと同様に、今回は、”dependency#”の”handle”の値で
ダンプファイル内を検索してみよう。

おそらくいくつかの情報が検索された後、オブジェクトの情報が出てくるはず
だ。

この関連オブジェクトに関しては、次回検証してみよう。

先週の”お題”に多数のご回答をいただきありがとうございました。
ほとんどのご回答が、今回のめるまがで紹介した手順でしたので、抽選を行
った上で当選したみなさんに、グッズをご送付したいと思います。

以上 ここ何日か避暑地の涼しさが続く茅ヶ崎にて