0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=3 Bytes=21)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=3 Bytes
=21)

2 1 INDEX (FULL SCAN) OF 'T1_IX' (NON-UNIQUE) (Cost=1 Card=3
)

Другой.

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=3 Bytes=21)
1 0 SORT (ORDER BY) (Cost=4 Card=3 Bytes=21)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=3 Byt
es=21)

3 2 INDEX (FULL SCAN) OF 'T1_IX' (NON-UNIQUE) (Cost=1 Card
=3)

У вас нет доп сортировки. У меня есть. И статистика выполнения показывает что таки да он результат отсортировал прежде чем мне выдать.
Откель у нас такая разница в выполнениях?

ЗЫ. Кстати что вы имели в виду под "Первое утверждение неверное"?

Да, вот этого я пока понять не могу :(
А что говорит select * from v$version; ??

Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
TNS for Linux: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

Утверждение относительно сортировки. Единств. проблема может возникнуть если у таблицы задран HWM.

Помедленней. Я в оракле не копенгаген пока что. Что есть HWM?

Сравниваем время и убеждаемся, что во втором случае время 0.07 сек не есть время полной работы запроса, а только время до получения первый строк выборки. У вас же в момент тестирования "fetch all records" не стоял, did it?

Конечно не стоял. При полном фетче

1) Без индекса
Select * From myprobtovar order by ID
20.048 сек

2)
Select /*+ FIRST_ROWS*/ * From myprobtovar order by ID
19.358 сек

Все равно запрос по индексу быстрей. Даже при полном фетче. И еще надо учесть что его скорость практически не зависит от количества полей. Так что он предпочтительней даже в случае фетч олл. Правда тут разница минимальна.

В статистике разница.
1)
Name,Last,Total
CPU used by this session,37
physical reads,437
physical writes,423
session logical reads,1578
sorts (disk),1
sorts (memory),0
sorts (rows),54210
table fetch by rowid,0
table scan blocks gotten,1566
table scan rows gotten,54210
table scans (long tables),1
table scans (short tables),0


2)
Name,Last,Total
CPU used by this session,43
physical reads,0
physical writes,0
session logical reads,73889
sorts (disk),0
sorts (memory),0
sorts (rows),0
table fetch by rowid,54210
table scan blocks gotten,0
table scan rows gotten,0
table scans (long tables),0
table scans (short tables),0

Кардинальная разница в
session logical reads и
sorts (rows)

Эа, ну нельзя же так ставить вопросы...

Если вам нужно это в сеть, юзверю, то так и декларируйте,
что вам нужно "побыстрее добыть первые записи, а потом, как получится".
Тогда вам в первых же строках документации (глава про оптимизатор) скажут, что вам нужны FIRST_ROWS.

Хотя странно, обычно CBO под FIRST_ROWS и оптимизирует. У вас случаем нигде не стоит чего-нибудь типа set optimizer mode=all_rows?

Конечно сорри, но... вроде ж не раз было сказано что запрос запускался в том числе и с прямым указанием индекса и с хинтом FIRST_ROWS . Беда в том что оракл на эти указания ... с высокой колокольни короче. Вопрос был именно в том что именно могло привести к такому его поведению.
set optimizer mode завтра гляну. Но как по моему это не должно оказывать влияние на реакцию на прямые хинты в запросе. Я неправ?

NLS_SORT очень близко к теме.По крайней мере очень похоже.

Я не могу взять в толк две вещи.
1. Почему этот параметр должен влиять на ордер по нумерик полям.
2. Зачем собственно ALTER SESSION NLS_SORT=....

По второму пункту. Если индекс уже построен по каким-то правилам, то как изменение флага внутри сессии может повлиять на то можно использовать этот индекс или нет?
Ну и напоследок вопрос бывалым.
Как обычно вы настраиваете все эти NLS ?

Огромное человеческое спасибо GDI. Без всяких демагогий ткнул носом туда куда нужно.

Теперь маленькое промежуточное резюме.

Суть проблемы сводилась к тому что NLS_SORT сессии не совпадал с NLS_SORT индекса. Посему оракл просто был уверен, что индекс для ордера не подходит никак. Выхода два. Либо для сессии установить NLS_SORT=BINARY, либо создать индекс с NLS_SORT=Russian . После чего Оракл без всяких дополнительных хинтов начинает юзать этот индекс в полный рост.

Остается вопрос с нестринговыми полями. Для всяких интегеров этот финт не проходит. К тому же мне совершенно неясно почему NLS_SORT вообще должен влиять на не стринговые поля. Куды глядеть еще?

ЗЫ. Срывать мне крышу сказками о том что вычитать хаотически все и потом отсортировать, будет дешевле чем сразу читать по индексу первые записи.. не надо. Если мои аргументы идут мимо кассы, то примите во внимание что оракл тоже так считает. Когда ему дают правильный индекс , то он с него слазит крайне неохотно. Даже когда ему говоришь чтоб оптимайзил под выдачу всех записей а не первых, он совершенно правильно продолжает юзать индекс.
Но все-таки... какой индекс будет ему правильным для нестринговых полей?