Настройки Oracle

[db]

Очевидным недостатком аксапты 3.0 в связке с ораклом является невозможность использования покрывающих индексов, если в нем есть хоть одно текстовое поле. Индексы строятся по функциям, запрос на выборку полей идет без функций (не критерии, а именно список полей) - соответственно вместо того чтобы взять значение поля непосредственно из индекса приходится ораклу лазить в данные таблицы - лишие действия, лишние шевеления жесткими дисками и т.д. Однако стоит отметить, что применение покрывающих индексов в аксапте явление нечастое, так что все в итоге не так уж смертельно

[Logger]

Цитата:

Сообщение от db

Очевидным недостатком аксапты 3.0 в связке с ораклом является невозможность использования покрывающих индексов, если в нем есть хоть одно текстовое поле. Индексы строятся по функциям, запрос на выборку полей идет без функций (не критерии, а именно список полей) - соответственно вместо того чтобы взять значение поля непосредственно из индекса приходится ораклу лазить в данные таблицы - лишие действия, лишние шевеления жесткими дисками и т.д. Однако стоит отметить, что применение покрывающих индексов в аксапте явление нечастое, так что все в итоге не так уж смертельно

Можно попробовать это обойти используя Group By
В этом случае в самом Select -е в списке полей идут функции от полей, а не сами поля
Правда это не всегда возможно.
Может получиться еще более тяжелый запрос...

[db]

Цитата:

Сообщение от Logger

Можно попробовать это обойти используя Group By
В этом случае в самом Select -е в списке полей идут функции от полей, а не сами поля
Правда это не всегда возможно.
Может получиться еще более тяжелый запрос...

Не, обмануть не получается
пишем в аксапте запрос

select ItemId from inventTrans group by ItemId;

На Oracle дейсвительно уходит функции от поля в списке выборки

SELECT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A
GROUP BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)
ORDER BY SUBSTR(NLS_LOWER(A.ITEMID),1,20)

На InventTrans достаточно индексов, содержащих SUBSTR(NLS_LOWER(A.ITEMID),1,20)

Но план запроса такой

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 8379
SORT GROUP BY 1 0 1
TABLE ACCESS FULL INVENTTRANS 2 1 1
Если отрезать GROUP BY и ORDER BY то все приходит в норму

SELECT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 420
INDEX FAST FULL SCAN I_177OPENITEMIDX 1 0 1

Если вместо GROUP BY сделать DISTINCT, то то же все по индексу

SELECT DISTINCT SUBSTR(NLS_LOWER(A.ITEMID),1,20)
FROM INVENTTRANS A

OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION
------------------------------ ------------------------------ ------------------------------ ---------- ---------- ----------
SELECT STATEMENT 0 3253
SORT UNIQUE 1 0 1
INDEX FAST FULL SCAN I_177OPENITEMIDX 2 1 1

В общем не получается получить и рыбку и удовольствие ...
Пробовал
ORA EE 9.2.0.6.0 64 bit Production под Linux
ORA EE 9.2.0.7.0 под Windows

Если у кого есть идеи как все таки заставить использовать данные из покрывающих функциональных индексов (кроме прямых SQL запросов) поделитесь пжл

Насчет отказа от функциональных индексов в принципе. Вроде как в 10R2 появился нормальный режим Case Insensitive (NLS_SORT=BINARY_CI, NLS_COMP=LINGUISTIC) Это бы позволило и от функциональных индексов избавится и с MONOCASE не заморачиваться.

10-ку ни разу не щупал и вообще спецом по ораклу себя не считаю.
Есть ли у кого опыт работы с Case Insensitive?

[Logger]

Цитата:

Сообщение от db

Не, обмануть не получается

Ну так я примерно это и имел в виду когда писал что "Может получиться еще более тяжелый запрос..."

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