Smart Flash Cache 簡単なパフォーマンス比較

SSDも新しくなったことで、快調に検証が進みそうです。
まず、Smart Flash Cache単体のパフォーマンスを比較するため、以下の3パターンのパフォーマンスを測定してみます。

1) 大きなテーブルをdirect path readで検索する
2) 大きなテーブルをdb file scattered readで検索する
3) 大きなテーブルをdb flash cache multiblock physical readで検索する

3)は見慣れないイベントですが、基本的には、全て同じテーブル(大きなテーブル)に対して

1) バッファーキャッシュを迂回してディスクを直接読み込む
2) バッファーキャッシュを経由してディスクを間接的に読み込む
3) バッファーキャッシュ+フラッシュキャッシュを経由して、ディスクを間接的に読み込む

ただし、今回のテストは、Smart Flash Cacheのパフォーマンスチェックなので、以下の条件を付けました。

* ご存知の方も多いと思いますが、11gR2から、通常のフルスキャン
   (今ままでのdb file scattered read)は、ある条件によりdirect path readに置き換えられます。
    これは、バッファーの再利用性が低いSQLだと(ある意味Oracleが勝手に)判断できる場合は、
    バッファー経由のI/Oを諦めてディスクと直接I/Oすることを意味します
* 今回のテストでは、db file scattered read と direct path readを使い分けたかったので、
   非公開のパラメータ"_very_large_object_threshold"を変えています。
* "_very_large_object_threshold"の単位は多分MBだと思いますが、このサイズを超える場合、
   大きいオブジェクトだと判断してdirect path readを選択するようです。なので、この値を非常に
   大きくすると、今ままで通り、db file scattered readを選択する可能性が高いということです。

1) テーブルのサイズは、必ずbuffer cacheのサイズを超える
2) テーブルのサイズは、flash cacheのサイズを超えない

つまり、buffer cacheを超える読み込みが発生するので、2)はパフォーマンス的に不利になるはずで、1)が多少有利になるはず。さらにSmart Flash Cacheの実力が本物なら3)のパフォーマンスが最高になるはずです。
まずは、結果を示します。



Smart Flash Cacheを使用したパフォーマンスが最高となっています。

では、いつものようにASH Viewerでその時の様子を見てみます。
* 1)のテストが図中のAに該当
* 2)のテストが図中のBに該当
* 3)のテストが図中のDに該当

その時の待機イベントも見てみましょう。(上記グラフの青で示されているUser I/Oを見てみます)

一応、思ったとおりの結果となっているようです。パターンAでは、待機クラスUser I/Oのdirect path readで待機しています。またパターンBでは、db file scattered read、パターンDでは、db flash cache multiblock physical readで待機しています。
以前の検証にてDiskとSSDの基本性能の違いをチェックしましたが、1MBのsequential readの性能で約3倍のパフォーマンスが違います。今回は(まだ、きちんと検証できていませんが)multiblock read count分のsequential readだとして16 * 8K = 128Kくらいのsequential readじゃないかと推察できます。1MBほど大きなサイズではないことが言いたいのですが、それにしてもDiskと比較して3倍のパフォーマンスアップにはなっていません。SSDをL2キャッシュとして使うSmart Flash Cacheはそれなりのオーバーヘッドがあるのかも知れません。