cardinality feedback
cardinality feedbackの確認方法。*1
3. "_OPTIMIZER_USE_FEEDBACK"という隠しパラメータ で制御できます。このパラメータの値をFALSEに変更したらCardinality Feedbackは行われません。デフォルトはTRUEです。
Cardinality Feedback機能によって作成された子カーソルは、V$SQL_SHARED_CURSOR表のUSE_FEEDBACK_STATS例が'Y'となっているかどうかで確認できます。
どちらかというと、この機能によるメリットより、リスクという観点でのデメリットが大きいかもしれない*2
オラクルは10gから自動クエリチューニング(Automatic Query Tuning)という名前でCardinality Feedback機能を紹介しました。予想の行数(Estimated Cardinality)と実際の行数(Actual Cardinality)を比べてその差を減らす方式がCardinality Feedback機能の動作原理です。このためにOPT_ESTIMATEヒントが追加されました。しかし、これはあくまでもチューニングオプティマイザエンジンにすみました。
11gR2でこの機能はチューニングエンジンにやまずにランタイムーエンジンまで適用されました。詳しい内容は上のリンクこ参照すればいいでしょう。簡単に整理すると次のとおりです。
クエリを行ったあと予想行数件数と実際行数件数の違いが大きすぎると判断されると該当実行計画は共有物不可の状態になって実際の行数件数をカーソルに書き込みます。しかし予想行数件数と実際行数件数の違いだけが唯一なファクターなのかは確実ではなんです。
あとで同一なクエリがまた実行されると最初の実行で書き込んでおいた行数をOPT_ESTIMATEヒントを通じてクエリに挿入します。すなわちCardinality Feedbackが行われます。
この過程はたった一度のみ行われます。すなわち最初のクエリだけがフィードバックの対象となります。
_OPTIMIZER_USE_FEEDBACKパラメーターを利用して制御できます。すなわちこのパラメーターの値をFALSEに変更したらCardinality Feedbackは行われません。私の個人的な意見を申し上げるとCardinality Feedbackがランタイムーエンジンまで適用されるはずだとはまったく期待しませんでした。でも結局そうなってしまいました。たぶん多くのシステムで熱いイシューになるはずです。
