разные планы выполнения одного запроса - как заставить CBO взять правильный? (10g!)

один и тот же запрос выполняю в SQL Plus (выполняется отлично!) и в моей программулине (выполняется плохо). В V$SQLAREA вижу два SQL_ID с разными планами выполнения. Разница в планах (смотрел dbms_xplan.display_cursor('5nx8hn25yux4b','','typical')) видна невооруженным глазом: хороший берет селективный индекс в большой таблице (в предикате стоит соответствующий критерий Х), а плохой отчего-то не признает индекс (в предикате критерий X появляется не сам по себе, а вместе с другими условиями, что приводит к TABLE ACCESS FULL). Статистики пересобирал с инвалидацией - результат нулевой. Что еще можно посмотреть, например в V$SQLAREA, чтобы понять, откуда/почему берется неправильный план и как заставить CBO взять правильный?

вроде нарыл, проблема известная - bind peeking (звиняйте чайника за наивные вопросы!)

Том Кайт советует в таких случаях делать CURSOR_SHARING=SIMILAR. У меня это не дало эффекта, сработало только CURSOR_SHARING=EXACT. Есть какая-то определенная причина, почему SIMILAR не работает? Что посоветуете, рыть дальше или удовлетвориться EXACT-ом?

Задвинутый чайник,

V$SQL_SHARED_CURSOR

ora601
Задвинутый чайник, V$SQL_SHARED_CURSOR

везде N стоИт :-((

Задвинутый чайник,

а значение-то переменной одно и то же передаёшь?

Задвинутый чайник,

чайник
в предикате критерий X появляется не сам по себе, а вместе с другими условиями, что приводит к TABLE ACCESS FULL

Мне кажется, вот тут надо уточнить. Покажите предикаты и планы.

Задвинутый чайник
один и тот же запрос выполняю в SQL Plus (выполняется отлично!) и в моей программулине (выполняется плохо). В V$SQLAREA вижу два SQL_ID с разными планами выполнения.

Две строки в V$SQLAREA, два разных SQL_ID ==> два разных запроса.
Один запрос с несколькими планами - это одна строка в V$SQLAREA, один SQL_ID, несколько строк в V$SQL.