Т.е. чтобы он при повторном выполнении запроса не брал план откуда-то из кэша, а построил его заново.
И кстати, можно ли однозначно утверждать, что предложение
Misses in library cache during parse: 0
из tkprof означает что он запрос заново не разбирал?

В принципе мне надо просто понять почему запрос выполняется не по хинту.
Тема это уже другая, но чтоб новую ветку не открывать...
Так вот, имеем табличку test

desc test
NUM1 NUMBER(10)
NUM2 NUMBER(10)
NUM3 NUMBER(10)
NAME VARCHAR2(100)
NAME1 VARCHAR2(100)

select count(*) from test;

COUNT(*)
----------
33280

по ней есть индекс test_idx

create index test_idx on test(num1, num2 desc, num3)

собираем статистику как положено:

exec dbms_stats.gather_table_stats(ownname=>'SCOTT', tabname=>'TEST', partname=>NULL);

PL/SQL procedure successfully completed.

exec dbms_stats.gather_index_stats(ownname=> 'SCOTT', indname=>'TEST_IDX', partname=>NULL);

PL/SQL procedure successfully completed.

выполняем запрос, а он вместо того штоб чесать по индексу, как в хинте сказано. вон чего вытворяет.

select /*+INDEX_ASC(test test_idx)*/ * from test
2 where (num1 > 222 or num1 = 222 and (num2 < 222 or num2 = 222 and (num3 >= 222)))
3 AND rownum < 10;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=208 Card=21320 Bytes
=4562480)

1 0 COUNT (STOPKEY)
2 1 CONCATENATION
3 2 FILTER
4 3 TABLE ACCESS (FULL) OF 'TEST' (Cost=104 Card=11960 B
ytes=2559440)

5 2 FILTER
6 5 TABLE ACCESS (FULL) OF 'TEST' (Cost=104 Card=11960 B
ytes=2559440)

я ему уж и alter system flush shared_pool говорил, и ткпрофом смотрел, что вроде по новой план строит. А по индексу он все равно не хочет.

Интересное наблюдение, если в выбираемые столбцы поставить не * а например num1 или num1, num2 т.е. столбцы участвующие в индексе то запрос отрабатывает используя хинт, т.е. по индексу. Как только добавляем столбец не входящий в индекс - пинцет, фул скан.
Сдается мне все это связано с тем, что num2 в индексе desc, но каким образом и как это вылечить, пока не ясно.

to SY: извини, что по русски, мой английский ужасен :))
Я согласен, что фул скан дешевле, т.к. он не может все данные взять из индекса, и 32000 строк это мало. Но есть одно маленькое гигантское НО, мне нужно чтобы результат запроса был отсортирован по указанному в хинте индексу.
Насколько я понимаю Оракл должен использовать хинт если это возможно в принципе, т.е. плюя на стоимость. Вот если бы индекса не существовало, или статистика была старая или что-то еще, тогда понятно, на нет и суда нет. А вот почему он в этом случае основывается на стоимости а не на хинте мне непонятно.