Показать сообщение отдельно
Старый 13.11.2006, 13:10   #16  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Можно попробовать это обойти используя Group By
В этом случае в самом Select -е в списке полей идут функции от полей, а не сами поля
Правда это не всегда возможно.
Может получиться еще более тяжелый запрос...
Не, обмануть не получается
пишем в аксапте запрос
X++:
select ItemId from inventTrans group by ItemId;
На Oracle дейсвительно уходит функции от поля в списке выборки

X++:
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 то все приходит в норму

X++:
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, то то же все по индексу

X++:
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?