Smart Flash Cacheの謎

そろそろ、Smart Flash Cacheのテストに戻ります。

基本的に、Smart Flash CacheはOLTP系で使うものだ。と先日書きました。しかし、テストでOLTP系のSQL(要はindex scan)を実行したら、なかなかbuffer cacheも汚れませんし、当然、flash cacheもキレイなままです。なので、通常はdirect path readを使ってしまうfull scanをscattered readに変える裏技を使って、一気に、buffer cacheを使いまくってみます。

そうすると、一つ、不思議な現象が起こっています。

"2回目のアクセスが、遅い"

ORDER_ITEMS表をfull scan(db file scattered read)させた際の経過時間を示してみます。



当然、1回目のアクセスはディスクから物理読み込みが発生しているので、遅いのは当たり前です。しかし、2回目のアクセスはbuffer cacheもしくは、flash cacheに乗っているはずなので、速い。ということを期待していたのですが。。。1回目のアクセスよりも遅くなってしまっています。

ちなみに3回目以降は、想定通りのスピードです。

何故なのだ!?

理由を考える前に、そもそも、flash cacheにちゃんとデータが乗っているのか?を見てみる。

ORDER_ITEMSのセグメントサイズは3840MBでした。これが、全部buffer cache(+flash cache)に乗っているのかを確認してみます。

以下のSQLでx$bhからサイズを確認します。

/* block sizeは8KB */
select  decode(state, 0, 'free', 1, 'xcur', 2, 'scur', 3, 'cr', 4, 'read', 5,
  'mrec', 6, 'irec', 7, 'write', 8, 'pi', 9, 'memory', 10, 'mwrite', 11,
  'donated', 12, 'protected', 13, 'securefile', 14, 'siop', 15,
  'recckpt', 16, 'flashfree', 17, 'flashcur', 18, 'flashna',state) status
,count(*)*8 / 1024 MB 
from x$bh
group by state

1: 起動直後
2: 1回目のアクセス
3: 2回目のアクセス
4: 3回目のアクセス
5: 4回目のアクセス

注目は、1回目のアクセスです。
セグメントサイズが3840MBにも関わらず、flashcur(これが、flash cahceにカレントモードで乗っているステータス)のブロックは2500MBにも満たない状況です。つまり、全部乗り切らなかった。2回、3回とアクセスすると、やっと、全ブロックがflash cacheに乗ったことが分かります。 

flash cacheに乗り切らなかった原因も謎なのですが、なぜ、ディスクからの物理読み込みが発生している1回目のアクセスより、2回目のアクセスが遅くなっているのか?

今後、もう少しちゃんと見てみる必要がありそうです。