ну планы то одинаковые только на первый взгляд - когда во втором случае ищет по KONH - то используется не 2 столбца как в первом случае - а один и число обработанных записей сразу выросло и затраты SPU очень во много раз


TABLE ACCESS BY INDEX ROWID KONH
| ( Estim. Costs = 898 , Estim. #Rows = 38.091 )
| Estim. CPU-Costs = 39.109.602 Estim. IO-Costs = 893
| Filter Predicates
|
|-- 3 INDEX RANGE SCAN KONH~0
( Estim. Costs = 295 , Estim. #Rows = 152.363 )
Search Columns: 1
Estim. CPU-Costs = 24.777.102 Estim. IO-Costs = 292
Access Predicates Filter Predicates

Да, действительно, прошляпил.

sibrin, тут вот какая штука:
По неведомой мне причине во втором плане потерялся мандант.
Т.е. поиск по KONH идет без учета манданта.
Далее скорость падает из-за использования HASH JOIN (из-за кол-ва записей KONH имеем классический случай - соединение маленькой и большой таблицы, тут оптимизатор абсолютно прав).

По поводу планов:
Что-то я не верю, что explain может возвращать некорректный план. Думаю здесь дело не в оракле. Сам такого не наблюдал.

В данном случае-то понятно, что Oracle не виноват, а виноват я, не заметив HASH JOIN А когда в упор что-то не видишь, можно и не такое предположить

А то, что в каких-то версиях Oracle были баги, почему бы и не поверить ROKO.

PS. Спасибо всем.

тогда возникает вопрос - почему в практически одинаковых запросах в одном случае NESTED LOOPS, а в другом HASH JOIN?

Так я написал:
1. во втором случае поиск в KONH идет без учета манданта (видимо, т.к. идет индекс скан по одному полю, вместо двух полей праймари ключа).
2. в результате имеем кучу записей из KONH, которую джойним с относительно небольшим кол-вом записей из cdhdr (вот здесь и идет отличие между планами). Т.е. имеем классический случай HASH JOIN'а.


Вообще да. В ранних версиях цифра.0.цифра и не такое бывает.

Ок, поставим вопрос по другому - почему во втором случае поиск идет без учета манданта? Запросы то практически одинаковые. Срыв башки оптимизатора?

Если б без манданта, то индекс бы вообще не взялся.
Поля то должны присутствовать в порядке их следования.

2 sibrin
а на вашей версии оракла еще есть разница между
cdhdr~udate >= '20070401'.
и
cdhdr~udate between '20070401' and '99991231' ?