(2)バッファキャッシュのバイパス機能 フル・スキャンした時にバッファキャッシュに載せるかどうかの判断をテーブルのサイズとバッファキャッシュのサイズを使用して行われます。具体的には、バッファキャッシュ・サイズの2%より大きいテーブルはLong tables、2%以下のテーブルはShort tablesと区別されて、バッファキャッシュに載せるかを判断します(以前は初期化パラメータで調整することも可能でしたが、この値を調整するのは簡単ではないためパラメータはなくなりました)。 Long tablesは、大きなテーブルをフル・スキャンでバッファキャッシュに読込むと、多くの再利用される予定のデータが追い出される可能性があるため、それを防ぐためにバッファキャッシュに載せないように動作します(正しくは、バッファキャッシュのマルチ・ブロック・リード分の領域に上書きします。フル・スキャンは、ある特定のデータしか必要としない場合や頻繁に使用しない場合でもすべてのデータを読込むので、それをバッファキャッシュに載せるのは効率が悪いからです)。そのため、フル・スキャンのときはShort tablesだけキャッシュに載せるようにしています(Statspackなどの統計情報には「table scans (long tables)、 table scans (short tables)」として出力されるので識別することができます)。このLong tablesのときにパラレル・フル・スキャンを行うとダイレクト・リードが動作します。これは、バッファキャッシュを経由しないでアクセスするI/Oです(このとき非同期I/Oを使用した先読みをすることで、更に高速にI/Oを行っています)ので、バッファキャッシュの競合も発生しないようになります。このダイレクトI/Oはパラレル・フル・スキャンやダイレクト・パス・インサートの場合に動作します。これによりバッファ・キャッシュから頻繁にアクセスするブロックを追い出さないようにしています。Oracle Database 11gR2からはIn-Memory PX(In-Memory Parallel Execution)が提供されていますので、この機能が動作するときはメモリに載せる閾値は異なりますので、注意して下さい。これについての説明は別の機会とさせていただきます。
第13回 キャッシュ周りについて (via shino)





















