2012/04/06に六本木アカデミーヒルズにてOracle OpenWorld 2012 Unconference presented by JPOUGとして多くのセッションが行われました。お越しいただいたい全ても皆様、セッションを担当して頂いた方々、Unconferenceの運営を任せて頂いた関係者各位に感謝申し上げます。
Unconferenceの中で、私も1つのセッションを担当しました。本質的には、
つまり、我々データベースに携わるものも変わらなければいけないし、変わらざるを得ない
ということですが、セッション終了後、私がセッション内でお題として扱った
の方法論について質問がありました。本セッションの本質ではないため、あまり説明はしませんでした。(本当は、ちょっと異なるI/Oパターンとしては無理くり感があり、恥ずかしかったので...) しかし、質問がありながら、公開しないほどのものではないので、本ブログにセッション内で使用した資料も合わせて掲載しておきます。
- DIRECT PATH READ
11gR2が検証環境でしたので、十分大きいセグメントに対しては自動的にdirect path readをオプティマイザが選択するので、本検証環境は何も特別なことは実施していません。
古いバージョンでは"_serial_direct_read"等にて制御可能です。
- DB FILE SCATTERED READ
"_very_large_object_threshold"はこちらで説明してました。
http://kojishinkubo.blogspot.jp/search/label/_very_large_object_threshold
- DB FILE SEQUENTIAL READ
簡単に検証可能ですので、皆さんも、プリミティブな世界をお楽しみください。
Unconferenceの中で、私も1つのセッションを担当しました。本質的には、
- プリミティブな世界の変化により、アプリケーションは変わらなければいけないし、変わらざるを得ない
- 今まさに、データベースにおいても、その変化が起きている
つまり、我々データベースに携わるものも変わらなければいけないし、変わらざるを得ない
ということですが、セッション終了後、私がセッション内でお題として扱った
同一のSQL文をネタにして、
同一の実行計画により、
異なるI/Oパターン
の方法論について質問がありました。本セッションの本質ではないため、あまり説明はしませんでした。(本当は、ちょっと異なるI/Oパターンとしては無理くり感があり、恥ずかしかったので...) しかし、質問がありながら、公開しないほどのものではないので、本ブログにセッション内で使用した資料も合わせて掲載しておきます。
- DIRECT PATH READ
11gR2が検証環境でしたので、十分大きいセグメントに対しては自動的にdirect path readをオプティマイザが選択するので、本検証環境は何も特別なことは実施していません。
古いバージョンでは"_serial_direct_read"等にて制御可能です。
- DB FILE SCATTERED READ
alter session set events '10949 trace name context forever, level 1'; alter session set "_very_large_object_threshold"=500000;
"_very_large_object_threshold"はこちらで説明してました。
http://kojishinkubo.blogspot.jp/search/label/_very_large_object_threshold
- DB FILE SEQUENTIAL READ
alter session set db_file_multiblock_read_count=1;
簡単に検証可能ですので、皆さんも、プリミティブな世界をお楽しみください。
direct path read のデメリットとして、バッファーキャッシュ上のダーティブロックのフラッシュ処理というのがあるような気がするのですが、そこらへんはどうお考えでしょうか？
返信削除状況によっては大きなオーバーヘッドになると思います。ただ、direct path read/scatter/sequentialは基本的に、オプティマイザが、過去の見地から見た最適解を見つけた結果だということが大事だと思っています。現時点のその判断が正しいか否か、少なくとも、私達は判断が必要で、最悪、その判断への介入も必要かもしれない。という素朴な気持ちの共有が本資料の目的であることをご理解下さい ^^)
返信削除