そろそろ、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, 'do...