Oracle9iに関する検証　その９

＜Oracle 9iに関する検証　その９＞
ペンネームちょびひげ

— データベース・バッファ上のデータ 4 -－

前回まで、3回に渡ってデータベース・バッファ（以下バッファ）上のデータ
を見る為にX$BH表を検証している。

今更ながらだが、X$BHのBHはBuffer Headerの略であると思われる。これはバ
ッファ上の領域を管理しているリストがバファのヘッダに存在し、X$BH表がそ
のリストを見ているからであろう。つまり、この表を見ればバッファの状態が
把握することが出来る。

前回は、X$BH表のTCH（バッファ上でアクセスされた回数）に注目してインデ
ックス検索時のバッファ上のデータをみた。今回はバッファ上に読み込まれた
データのLRU_LIST上での移動を、TCHとLRU_FALGの値の変化に着目して、順を
追って見てみたい。

1．＜準備＞
まずは、適当な検索を行いTCHの値を2にする。つまり、インデックス検索で一
度バッファ上に載せてからもう一度、同様のインデックス検索を行い、TCHの
値を2にしている。

# インデックス検索を実行

SQL> select * from block4 where id = 13110;

— しばらく置いて —

# もう一度実行

SQL> select * from block4 where id = 13110;

# バッファ上の様子を検索

SQL> select
  2   o.object_name, blsiz , count(*) blocks , lru_flag , tch, state
  3  from x$bh b , dba_objects o
  4  where b.obj = o.object_id
  5    and o.object_name in ('BLOCK4','BLOCK4_IDX')
  6  group by b.blsiz, o.object_name, lru_flag, tch, state;

OBJECT_NAME          BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
--------------- ---------- ---------- ---------- ---------- ----------
BLOCK4                4096          1          0          2          1

2．＜実行＞
ここで、通常のトランザクションを発生させバッファを適度に使用するように
する。これは先ほどインデックス検索を行なったデータをバッファ上から追い
出す為である。

トランザクション実行！（と言っても通常の運用環境です。）

3．
＜観察 1＞
先ほどのバッファ上のブロックの変化を見て行こう。

OBJECT_NAME          BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
--------------- ---------- ---------- ---------- ---------- ----------
BLOCK4                4096          1          8          0          1

おおっと！LRU_FLAGが8になった。
つまり、コールドな領域の末尾側からホットな領域のMRU側に移動されたこと
を意味する。（先程からホットな領域へ”移動”という言葉を使っていますが
、実際はLRUリストの更新です）また、TCHが0にリセットされていることに注
目して頂きたい。

＜観察 2＞

OBJECT_NAME          BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
--------------- ---------- ---------- ---------- ---------- ----------
BLOCK4                4096          1          0          0          1

-----------------------------
OBJECT_NAME          BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
--------------- ---------- ---------- ---------- ---------- ----------
BLOCK4                4096          1          4          0          1

ん！LRU_FALGが 0 → 4 に変更した。
これはホットな領域から追い出されたことを意味しているようである。

＜観察 3＞

レコードが選択されませんでした。

バッファ上からなくなったようである。

以上で、バッファ上のブロックの、LRU管理の流れが分かって頂けただろうか。
ちなみにホットな領域にブロックが載った場合も、ホットな領域上でTCHの値
が “_db_aging_hot_criteria” で指定されている値（2）以上になった場合
は、ホットな領域からコールドな領域に移される（LRU_FLAGが0になる）かわ
りに、一度TCHの値がリセットされホットな領域のMRU側に移動される。つまり、
常に一定のアクセスのあるブロックは、ホットな領域に残りつづけるのである。

最後に、その他の隠しパラメータもいくつか見てみたいと思う。
ただし、これらはあくまでも検証結果による推測であることをお断りしておき
たい。

・_db_aging_touch_time （デフォルト：3）
  一度ブロックにアクセスしてTCHの値がカウントアップされてから次のカウ
  ントアップを受け付けるまでの時間。

・_db_aging_stay_count （デフォルト：0）
  ホットな領域に移動された時にTCHがリセットされる値

以下"_db_aging_hot_criteria"を"5"、"_db_aging_stay_count"を"
2"にして検証した結果である。

OBJECT_NAME      BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
----------- ---------- ---------- ---------- ---------- ----------
BLOCK4            4096          1          0          5          1

                         ホットな領域に移動 ↓         ↓TCHのリセット

OBJECT_NAME      BLSIZ     BLOCKS   LRU_FLAG        TCH      STATE
----------- ---------- ---------- ---------- ---------- ----------
BLOCK4            4096          1          8          2          1

今回はバッファ上のブロックのLRU管理の隠しパラメータをいくつか見たが、
これはあくまでもバッファ上のデータの動きを理解する為にしておいたほうが
良いであろう。

今回の検証の際も”_db_aging_touch_time”を”0″にしたところホットな領
域にデータが移されない現象が見られた。

以上、茅ヶ崎にて

Oracle9iに関する検証 その９