10046 trace name context forever

従来からフルスキャン(通常 db file scattered read)をバッファーキャッシュを迂回するdirect path readに変更する手法としていくつか手段がありました。 * 今回は、Parallel Queryは除外 1. "_serial_direct_read"を設定する SQL> alter session set "_serial_direct_read"=true; 2. event 10355を設定 $ oerr ora 10355 10355, 00000, "turn on direct read path for scans" // *Cause: // *Action:  enable direct async read for scans 11gR2からは、フルスキャンでdb file scattered readを使うのか、direct path readを使うのか、Oracleが自動で決定しているようです。 勝手に選択されるのも、時と場合によっては問題になる可能性があるので、その仕組みを少し調査してみます。 以下の隠しパラメータが影響して、I/Oの制御を行っているようです。 "_small_table_threshold" lower threshold level of table size for direct reads "_very_large_object_threshold" upper threshold level of object size for direct reads セグメントサイズ > 5 * "_small_table_threshold" * blocksizeの場合にdirect path readを選択するようになります。 ただし、これは、event 10949で制御が可能です。 $ oerr ora 10949 10949, 00000, "Disable autotune direct path read for full table scan" // *Cause: // *A...

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を選択する可能性が高いとい...